Android — Сontinuous Integration

Не буду описывать в сотый раз что такое CI и зачем это нужно. Выдумщиком данной концепции считается, не безизвестный, Мартин Фаулер, а с его трудом можно ознакомиться здесь ^[1].

Я же хочу в серии из нескольких статей рассказать о том, как организовать разработку Android приложений с использованием непрерывной интеграции. Для меня было не ожиданностью, что несмотря на всю популярность CI, в интернете до сих пор не существует подробной интсрукции, по шагам, для новичков, даже на английском языке, не говоря про русский (ну или я таких попросту не нашел).

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

Я буду рассматривать все примеры на следующем наборе инструментов/технологий, хотя это не принципиально и, например, GIT может быть легко заменен на Mercurial, а TeamCity на Jenkins:

VCS — GIT
Testing — Emulators, Android Instrumentation Framework, JUnit, Robotium, Robolectric, Mockhito
Building — Maven + android-maven-plugin
IDE — IntelliJ IDEA
Хранилище артифактов — Nexus
CI server — TeamCity

Что имеется:

Итак, исходные коды проекта лежат в GIT-репозитории, там же хранятся необходимые библиотеки, все участники проекта коммитят в одну главную master-ветку, оттуда же собираются сборки для релиза. Понятие о тестах отсутствует, сборка осуществляется средствами IntelliJ IDEA: Tools -> Android -> Export Signed Application Package. Собранные артифакты между участниками процесса распространяются по почте, скайпу и прочему. Подготовка очередной релизной версии может занимать до нескольких часов: переключение файла конфига, изменение номера версии в приложении, коммит релиза в репозиторий, создание тега с номером версии на коммит, последующая проверка, что все собрано как надо, приложение смотрит на нужный сервер и подписано необходимым ключем и прочее. И несмотря на все проверки и меры предосторожности не стоит забывать о человеческом факторе.

Что хотим получить:

Исходные коды по прежнему лежат в GIT :) Модель ветвления веток в репозитории организована в соответсвии с данным трудом ^[2] и этим замечанием ^[3], помогающем учесть фазу тестирования и исправления найденных ошибок. (В дальнейшем это позволит нам проще настроить TeamCity, да и вообще существенно облегчит разработку, подготовку к релизу и дальнейшую его поддержку). Зависимости автоматически поддтягиваются из Nexus во время сборки. Сборка возможна двумя вариантами:

• через IDE, с возможностью подключения дебага и создания различных run-конфигураций средствами IDEA (удобно при локальной разработке, для быстрого запуска отдельных тестов и т.д.)
• maven'ом, в один клик или полностью автоматически

Проект состоит из трех модулей:

• Root — корень проекта содержит два других вложенных модуля
• App — модуль с приложением. Помимо самого приложения, содержит JUnit и Robolectric юнит-тесты (вкратце — Robolectric ^[4], библиотека позволяющая запускать Android код в настольной JVM, что существенно ускоряет тестирование в отличие от варианта с Instrumentation тестами).
• Test — модуль с интеграционными тестами. Тесты написаны либо с использованием стандартных средств платформы для тестирования (Instrumentation Framework ^[5]), либо с использованием Robotium ^[6].

Build-скрипт для maven позволяет собирать приложение в трех конфигурациях: development, test и production, различиющихся соответсвующими настройками (адреса серверов, задержки и таймауты, debug-флаг и т.д.). Во время сборки запускаются юнит- и интеграционные тесты.

CI-сервер осуществляет следующие сборки:

• Development — на каждый пуш в develop ветку. Цель сборки — максимально оперативное выявление ошибок типа «забыл закоммитить файл, проект не собирается у других участников команды».
• Nightly build — сборка всех трех конфигураций с нуля и прогон тестов
• UAT — сборка, собирающая релиз кандидаты в ходе тестирования и исправления найденных багов
• Release — релизная протестирования сборка для выкладывания в маркет

На каждую успешную UAT или Release сборку в репозитории создается тег вида rcX.X.X-X или vX.X.X соответсвенно. Если билд завален: не компилируется, сломана часть тестов и т.д. — отправляется письмо с алярмой заинтересованным лицам.

Готовые артефакты для тестирования или деплоя в продакшн участниками проекта забираются только с CI-сервера, никакой пересылки вручную. Не нужно задумываться о файле с конфигами проекта или создании тегов в репозитории все происходит «само». Время на подготовку и сборку нового релиз-кандидата для тестирования или релизной версии — 2-5 минут.

В следующей статье напишем наш pom.xml для мавена и потихоньку начнем воплощать задуманное

P.S. Пока готовил статью на Хабре появилась публикация ^[7] на данную тему, тем не менее продолжу писать и поделюсь и своим опытом

Автор: TheDimasig