Pull to refresh

Android — Сontinuous Integration. Часть 1

Reading time 3 min
Views 20K
Не буду описывать в сотый раз что такое CI и зачем это нужно. Выдумщиком данной концепции считается, не безизвестный, Мартин Фаулер, а с его трудом можно ознакомиться здесь.

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

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

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

VCS — GIT
Testing — Emulators, Android Instrumentation Framework, JUnit, Robotium, Robolectric, Mockito
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. Пока готовил статью на Хабре появилась публикация на данную тему, тем не менее продолжу писать и поделюсь и своим опытом
Tags:
Hubs:
+13
Comments 15
Comments Comments 15

Articles