CI TeamCity — Автоматизация build процессов Android и UI тестирования

В этой статье предлагаю Вашему вниманию инструкцию по установке и настройке TeamCity для автоматизации сборки и тестирования Android проектов под Windows.

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

Цели:

При обновлении кода проекта должно происходить:

• Автоматическая сборка проекта
• Прогон UI автотестов
• Экспорт APK файлов debug и release для последующего ручного тестирования
• Уведомление всех участников команды разработки о результатах

План:

1. Установка и настройка Java JDK
2. Установка и настройка Android SDK
3. Установка отдельного Gradle для дебага
4. Подготовка Android проекта
5. Установка TeamCity Server и Build Agent
6. Настройка TeamCity Project → Build для билда проекта и получения установочного APK
7. Настройка build steps c UI автотестами

Основная часть

1. Установка и настройка Java JDK

Вопреки распространенному мнению об установке последней версии Java, JetBrains на своём официальном сайте публикует рекомендованную версию Java SDK: ссылка

Устанавливаем рекомендованную версию: ссылка

Также устанавливаем Environment Variables:

• JAVA_HOME – путь к папке с SKD Java для использования CI.
  
  Пример:
  
  C:\Java\jdk1.8.0_181
  Лучше ставить в System variables.
• Path — путь к папке с SKD Java для использования из командной строки.
  
  Пример:
  
  C:\Java\jdk1.8.0_181\bin
  Лучше ставить в User variables.

Проверяем правильность установки:

В CMD в любом каталоге вводим: java -version

Java должна ответить, что она есть:



2. Установка и настройка Android SDK

Мы не будем ставить отдельно Android SDK tools. Android запретил создавать проекты из командной строки. Также будет удобнее дебажить возможные ошибки, если мы сразу установим Android Studio.

Устанавливаем последнюю версию: ссылка

Также устанавливаем Environment Variables:

ANDROID_HOME
Пример: C:\Users\1\AppData\Local\Android\Sdk

ANDROID_AVD_HOME
Пример: C:\Users\1\.android\avd

Path:

Пример: C:\Users\1\AppData\Local\Android\Sdk\platform-tools\ — запуск утилит из консоли нами и CI.

Проверка: набираем в CMD: adb --help

Получаем информацию по актуальной версии и доступных командах:



Path:

Пример: C:\Users\1\AppData\Local\Android\Sdk\emulator\ — запуск эмулятора из консоли нами и CI.

Проверка: набираем в CMD emulator -version

Получаем информацию по актуальной версии:



3. Установка Gradle

Gradle входит в Android Studio, но мы поставим еще отдельный для дебага из консоли.

Версия не важна, т.к. подразумевается, что проект будет запускаться через Gradle wrapper.

Предлагаю установить версию аналогично используемой в проекте, например Gradle 3.3. Ссылка.

Также устанавливаем Environment Variables:

GRADLE_HOME – надобности нет, т.к. CI будет использовать Gradle Android Studio.

GRADLE_USER_HOME

Пример: c:/gradle-cache

Актуально для Windows Server, т.к. без него, во время сборки проекта, все выкачанные Gradle библиотеки будут складироваться в C:\Windows\System32\config\systemprofile\.gradle и далее CI не сможет получить доступ к этим файлам.

Path:

C:\Gradle\gradle-3.3\bin — путь к папке Gradle для удобного использования из командной строки.

Проверка: набираем в CMD gradle -v

Получаем информацию по актуальной версии:



4. Подготовка Android проекта

4.1. Создадим тестовый проект в Android Studio.

Тип Activity – Bottom Navigation Activity. Пригодится далее для создания UI теста.

4.2. Отключаем Gradle Daemon на постоянной основе, чтобы в CI не спавнились Gradle Daemon:

Дописываем в файле gradle.properties:
add org.gradle.daemon=false

4.3. Также дописываем в файл .gitignore (на свой вкус)

.gradle
.idea
/build/
local.properties
чтобы в VCS не ушли лишние файлики.

4.4. Создаём хранилище ключей (или используем существующий) в папке проекта. Ссылка.

4.5. Добавляем в Gradle ссылки на хранилище ключей, чтобы мы смогли собрать полноценный APK.

Пример:

android{  
    ... // существующий код
    signingConfigs {
        release {
            storeFile file("keystorefile.jks") //ссылка на файл с ключами в корневой папке проекта
            storePassword "Password" //пароль хранилища ключей
            keyAlias "android" // keyAlias, который задавали при создания ключа
            keyPassword "Password" //пароль ключа APK
        }
    }

    ... // существующий код
     buildTypes {
        release {
            ... // существующий код
            signingConfig signingConfigs.release //подпись релизного APK
        }
    }
} 

4.6. Для проверки работоспособности системы мы соберем новый проект из командной строки. Вводим в CMD:

cd <папка в проектом>

Например: C:\Users\1\Documents\GitHub\Command2

Переходим в проект.

Вводим:

gradlew assembleDebug

Ждем завершение сборки.

Если всё хорошо, то получаем результат BUILD SUCCESSFUL.



Идём в папку проекта: app\build\outputs\apk\debug

В ней находится свежий APK файлик, который можно установить на девайс и проверить, всё ли работает.

4.7. Также мы проверим, запускается ли SDK tools и AVD manager.

4.7.1. Запускаем Android Studio и создаем эмулятор. Можно, конечно, в командной строке создать, но у нас есть установленная UI оболочка, грех ей не воспользоваться.

Tools → AVD Manager:



Версия SDK созданного эмулятора должна быть не меньше нашего SDK проекта.

4.7.2. Создали эмулятор. Проверим его запуск из консоли. Вводим в командной строке:

start /min emulator -avd <имя девайса>

Пример:

start /min emulator -avd Pixel_2_API_25

Обратите внимание, что мы используем функцию /min для запуска эмулятора в фоне. Иначе он бы не дал вводить новые команды в CMD.
Девайс запущен:



4.7.3. Проверяем установку собранного APK.

Вводим в CMD:

adb install <path_to_apk>

Пример:

adb install C:\Users\1\Documents\GitHub\Command2\app\release\app-release.apk

Успешно:



4.7.4. Проверяем запуск установленного APK.

Вводим в CMD:

adb shell monkey -p <путь к пакету со стартовым активити> -c android.intent.category.LAUNCHER 1

Пример:

adb shell monkey -p com.panarik.command -c android.intent.category.LAUNCHER 1

Приложение запустилось:



4.7.5. Заливаем проект на удаленный репозиторий, к примеру, на GitHub. Проверяем, будет ли скачиваться проект:

Устанавливаем Git BASH (это если используем Git VCS). Ссылка.

Клонируем проект из удаленного репо. Вводим в консоли Git BASH:

git clone <ссылка на проект.git>

Пример:

git clone https://github.com/panarik/Command2.git

Видим результат. Проект скопировался в локальную папку:



Всё готово для установки и настройки TeamCity. Почему мы занимаемся упражнениями с командной строкой, а не сразу установкой TeamCity. Гораздо удобнее заранее удостоверится в работоспособности проекта, чтобы в дальнейшем было легче локализовать возможные баги на стадии билда в TeamCity.

5. Установка TeamCity Server и Build Agent

Процесс установки детально прописывать не буду. Он есть в официальном гайде и многих других источниках. Порт сервера TeamCity предлагаю выставить нестандартный, чтобы его было сложнее сканами портов вычислить.

6. Настройка TeamCity Project → Build

В общих настройках нужно лишь задать путь к выводу APK:

Пример:

app\build\outputs\apk\release\app-release.apk



6.1. Настройка TeamCity VCS Roots

Все по стандарту. В нашем проекте мы используем Git, поэтому вводим его и ссылку на удаленное репо. Пример:

https://github.com/panarik/Command2.git



6.2. Настройка TeamCity Build Configuration

Добавляем Build Step, который будет компилировать проект и выводить APK. В нашем проекте мы используем Gradle.

Вводим в поле Gradle tasks:

clean build assembleDebug --no-daemon (--no-daemon на всякий случай, а так должна работать приписка в файл, которую мы сделали в п. 4.2)



Нажимаем Run, получаем APK.

7. Настройка build steps c UI автотестами

Подобрались к самому интересному, а именно, автоматический запуск UI тестов.

Степы будем запускать с помощью .BAT файлов. Так гораздо удобнее писать код, менять его на лету без необходимости лезть в UI TeamCity и т.д.

7.1. Сначала создадим build step с запуском эмулятора.

Можно сделать URL до BATника полностью, я, для удобства, сделал Environment в TeamCity BAT_FILES c путём к папке с BATниками:



В файле прописываем код запуска эмулятора.

Пример:

start /min "emulator" /D "C:\Users\1\AppData\Local\Android\Sdk\emulator" emulator.exe -avd Pixel_2_API_25 -no-snapshot-save -no-boot-anim
Список команд и параметров на офф сайте: ссылка.

7.2. Создадим build step с паузой, пока загрузится эмулятор. Можно сразу в .BAT первого степа прописать, но так будет нагляднее.

Пример такой команды, который подсмотрел на просторах интернета:

adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done; input keyevent 82'

Из UI будет выглядеть так:



Список всех команд на офф сайте: ссылка.

7.3. Запускаем тест.

Также из командной строки. Тут всё индивидуально.

Пример команды:

gradlew connectedDebugAndroidTest

7.4. Останавливаем эмулятор.

Пример команды:

adb -s emulator-5554 emu kill

Процесс завершен.

Также можно отдельным степом сделать выгрузку отчета. По умолчанию он сохраняется в папке с проектом.

Большое спасибо Вам за внимание!

Если у кого-нибудь есть совет по улучшению кода для степов, и предложения по улучшению, буду очень благодарен.