CI-функции

Ниже приведены некоторые функции, которые можно найти в большинстве систем CI.

Среда

Важно выбрать и понять аппаратную и программную среду, в которой система выполняет рабочий процесс. Важные соображения для приложений Android:

• Платформа : Linux, Mac, Windows и их версии.
• Доступная память . Создание приложений и запуск эмуляторов могут использовать много оперативной памяти, и часто необходимо настраивать такие параметры, как размер кучи JVM, чтобы избежать ошибок нехватки памяти.
• Предустановленное программное обеспечение . Системы CI обычно предоставляют образы с большой коллекцией уже доступных инструментов, таких как Java Development Kit (JDK), Android Software Development Kit (SDK), инструменты сборки, платформы и эмуляторы.
• Архитектура бегуна и набор инструкций : ARM, x86. Это важно при использовании эмуляторов.
• Переменные среды : некоторые из них задаются системой CI (например: ANDROID_HOME ), и вы можете установить свои собственные, например, чтобы избежать жесткого кодирования учетных данных в вашем рабочем процессе.

Вам следует учитывать множество других аспектов, таких как количество доступных ядер и возможность виртуализации для запуска эмуляторов.

Журналы и отчеты

Если на каком-то этапе происходит сбой, система CI уведомляет вас и обычно не позволяет объединить изменения. Чтобы узнать, что пошло не так, поищите ошибки в журналах.

Кроме того, при сборке и тестировании создаются отчеты, которые обычно сохраняются как артефакты этой конкретной сборки. В зависимости от системы CI вы можете использовать плагины для визуализации результатов этих отчетов.

Время выполнения кэша и CI

Системы CI используют кэш сборки для ускорения процесса. В простейшей форме они сохраняют все файлы кэша Gradle после успешной сборки и восстанавливают их перед новой. Это зависит от функции кэша сборки Gradle и должно быть включено в вашем проекте.

Некоторые способы улучшения времени работы и надежности включают в себя:

• Модули : определение модулей, на которые влияют изменения, их сборка и тестирование.
• Пропустить кеши . Если сборка включает скрипты, измененные разработчиком, игнорируйте кеши сборки. Безопаснее строить с нуля.
• Шард-тесты : особенно инструментальные тесты. Может быть полезно сегментировать тесты на нескольких устройствах. Это поддерживается средством запуска Android, управляемыми устройствами Gradle и тестовой лабораторией Firebase.
• Шард-сборки : вы можете разделить сборку на несколько экземпляров сервера.
• Удаленный кеш : вы также можете использовать удаленный кеш Gradle .

Повторить неудачные тесты

Ненадежность относится к тестам или инструментам, которые периодически терпят неудачу. Всегда следует стараться находить и устранять проблемы, которые приводят к ненадежным сборкам и тестам, но некоторые из них трудно воспроизвести, особенно при запуске инструментальных тестов. Общая стратегия состоит в том, чтобы повторять тестовые прогоны в случае неудачи, вплоть до максимального количества повторных попыток.

Не существует единого способа настройки повторных попыток, поскольку они могут происходить на нескольких уровнях. В следующей таблице описаны действия, которые вы можете предпринять в ответ на нестабильный сбой теста:

Важно регистрировать и отслеживать, какие части системы нестабильны, и инвестировать в поддержание надежности и скорости CI, полагаясь только на повторные попытки.