Не буду описывать в сотый раз что такое CI и зачем это нужно. Выдумщиком данной концепции считается, не безизвестный, Мартин Фаулер, а с его трудом можно ознакомиться здесь.
Я же хочу в серии из нескольких статей рассказать о том, как организовать разработку 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 :) Модель ветвления веток в репозитории организована в соответсвии с данным трудом и этим замечанием, помогающем учесть фазу тестирования и исправления найденных ошибок. (В дальнейшем это позволит нам проще настроить TeamCity, да и вообще существенно облегчит разработку, подготовку к релизу и дальнейшую его поддержку). Зависимости автоматически поддтягиваются из Nexus во время сборки. Сборка возможна двумя вариантами:
- через IDE, с возможностью подключения дебага и создания различных run-конфигураций средствами IDEA (удобно при локальной разработке, для быстрого запуска отдельных тестов и т.д.)
- maven'ом, в один клик или полностью автоматически
Проект состоит из трех модулей:
- Root — корень проекта содержит два других вложенных модуля
- App — модуль с приложением. Помимо самого приложения, содержит JUnit и Robolectric юнит-тесты (вкратце — Robolectric, библиотека позволяющая запускать Android код в настольной JVM, что существенно ускоряет тестирование в отличие от варианта с Instrumentation тестами).
- Test — модуль с интеграционными тестами. Тесты написаны либо с использованием стандартных средств платформы для тестирования (Instrumentation Framework), либо с использованием Robotium.
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. Пока готовил статью на Хабре появилась публикация на данную тему, тем не менее продолжу писать и поделюсь и своим опытом
Автор: TheDimasig
