CI: Jenkins

В Android-проектах используется CI/CD-решение Jenkins

Данное решение позволяет организовать сборку, тестирование и доставку полученного артефакта до целевых групп/ресурсов.

---

Работа Jenkins

На текущем этапе, как правило, Jenkins в Android-проектах настроен на работу по следующим этапам:

1. Получение из Git-репозитория актуальной ветки проекта
2. Сборка артефакта проекта
3. Тестирование полученного артефакта с помощью написанных в проекте тестов. На данный момент это только тесты JUnit, которые раскрыты в статье о тестировании. Инструментальное тестирование на данный момент не реализовано. На этом же этапе код проверяется встроенным статическим анализатором Android - Lint, формируя отчёт об обнаруженных проблемах в коде
4. Архивация полученных результатов тестирования (этап №3)
5. Публикация собранного артефакта и оповещение целевых групп (деплой артефакта в систему Fabric Beta, оповещение в чате проекта об окончании сборки)

Настройка процедуры, которую я привел выше, производится в рамках сценария Jenkins'а под названием Pipeline. Для данного сценария необходимо вручную, в специальном скрипте,

---

Создание новой сборки Jenkins'а

Для создания новой сборки, необходимо:

1. В главном терминале Jenkins'а выбрать "Создать Item"
2. В открывшемся окне ввести имя новой сборки, которое будет отображаться в списке сборок. Тут следует учесть, что для разных платформ удобно указывать название платформы в суффиксе через нижний слэш (прим. someproject_android)
3. Выбрать тип сборки Pipeline и нажать внизу на "Ок"
4. Далее мы перейдем на экран настройки сборки. Будем идти по порядку:

• Ставим галку напротив "Удалять устаревшие сборки", указав стратегию Log Rotation, и указав в обоих полях значение "1" ("Сколько дней хранить результаты сборки" и "Сколько последних сборок хранить")
• Ставим галку напротив "Это - параметризованная сборка". Создаем параметры сборки по логике: Choiсe parameter (используется для ограниченного выбора из заранее определенного числа элементов, можно использовать для Flavor'ов, BuildType'ов и прочих ограниченных выбором вещей), Multi-line String Parameter (идеально подходит для описания изменений в версии билда, т.е. ReleaseNotes), String (подходит для указания ветки Git'а, с которой стоит получить изменения на этапе сборки, т.е. Branch. Тут для этого кейса стоит установить галку "Trim the string" для обрезания возможных пробелов в строке)
• Ставим галку напротив Trigger builds remotely и устанавливаем значение unitbeanRemotelyBuild. Данное значение позволяет запускать сборки проектов извне, с помощью специальной URL-команды (временно сломана со стороны Jenkins'а, в поисках решений)
• Переходим к финальному полю, основному телу Pipeline-скрипта. Образец, на который можно ориентироваться, можно взять из смежных _android-проектов. Сам скрипт базируется на языке Groovy.

5. Убедиться, что в Android-проекте настроена работа в среде Jenkins:

android {
    ..
    buildTypes {
        release {
            ..
            ext.betaDistributionGroupAliases="android-ub-testers, all-unitbean-android-"
            ext.betaDistributionReleaseNotesFilePath="${rootProject.projectDir}/releaseNotes.txt"
        }
        debug {
            ..
            ext.betaDistributionGroupAliases="android-ub-testers, all-unitbean-android-"
            ext.betaDistributionReleaseNotesFilePath="${rootProject.projectDir}/releaseNotes.txt"
        }
    }
}

Прим.: поле ext.betaDistributionGroupAliases указывает, на какие группы тестировщиков в Fabric посылать тестовые сборки. Его следует брать из Fabric/Manage Groups/<group>/Alias; поле ext.betaDistributionReleaseNotesFilePath указывает, из какого файла будут считаны примечания к релизу

6. После того, как проект создан и настроен, можно запускать его сборку. Но тут следует учесть, что при сборке Android-приложений, как правило, требуется JKS-файл с подписью. И по стандарту его не следует хранить в индексе Git'а, что может создать ситуацию, когда проект падает при сборке на этапе "Build" с обозначением соответствующей ошибки с ключами. В данном случае следует вручную с помощью bash положить .jks-файл в директорию проекта. Данная процедура описана в блоке чуть ниже

---

Добавление файлов в директорию сборки проекта

Для получения доступа нужно зайти в корпоративный ЯДиск/Projects/Jenkins/Jenkins sudo.rtf Так лежат доступы для получения достижения папки root.

Процедура:

1. Положить с помощью FileZilla файл в общедоступную папку
2. Зайти под root в Jenkins с помощью ssl
3. С помощью root доступа переместить файл из общедоступной папки в папку проекта

---

Сценарий добавления собственной идеи в Jenkins:

1. Самостоятельно найти реализацию для Jenkins'а, зачастую выступающую в виде плагина для системы. Изучить страницу плагина на предмет необходимых данных для работы оного и выдаваемых артефактов работы на выходе. Если все устраивает, то переходить к п.2, если нет - то предпринять попытку самостоятельно доработать плагин для синхронизации его работы с текущей реализацией системы (например, создавать временный файл для передачи данных в другие места)
2. Обратиться к администрирующему Jenkins человеку. На данный момент это Владислав Кирилличев (@vlad.kirilichev в Slack'е) с просьбой подключить необходимый плагин к системе и произвести прочие манипуляции, в случае, если есть необходимость.
3. Когда плагин подключен и выполнены манипуляции, то для использования плагина можно сразу преступить к редактированию Pipeline-скрипта, либо обратиться ко встроенной утилите Pipeline Syntax, с помощью которой все встроенные плагины и системы умеют генерировать Pipeline-скрипты для встраивания их в основной скрипт проекта. После генерации необходимого скрипта, то нужно интегрировать его в основной скрипт, таким образом, начав использовать новый подключённый плагин в Jenkins'е
4. Запустить сборку проекта с обновлённым Pipeline-скриптом, проверяя, таким образом, целостность и работоспособность нового решения

---

Необходимые ссылки:

Консоль Jenkins'а

Внешние материалы:

Continuous Integration для новичков

Феншуйная автоматизация CI & CD с помощью Jenkins и Jira