Teamcity что это для чайников
Непрерывная интеграция и TeamCity
Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.
Вам потребуется самостоятельно скачать и установить версию TeamCity подходящую для вышей платформы, а так же произвести установку инструментария из прошлой статьи, благо все это ставится без особых проблемы, но если что задавайте вопросы в комментариях. Так же вам потребуется какой-то существующий PHP проект уже хранящийся в SVN (или любой другой аналогичной системе).
TeamCity GUI будет доступен через HTTP на установленном хосте, после авторизации и конфигурирования главная страница будет выглядеть примерно как на скриншоте ниже. Каждый проект имеет свой собственный блок при большом количестве проектов можно настроить их видимость, так же статус каждого блока (свернут, развернут) запоминается. В проектах представлены конфигурации, для каждой из которое есть статус строка, в которой отображается информация о номере билда, индикатор (4 состояния: завершен успешно, завершен с ошибками, выполняется, выполняется с ошибками — все они интуитивно понятны), небольшое текстовое описание билда в котором сейчас можно наблюдать данные о количестве тестов и информацию об анализе кода. Почти у всех элементов есть AJAX подсказки которые отображают расширенную информацию и / или навигацию.
Для создания проекта необходимо перейти в раздел «Administration», ниже вы можете увидеть что у нас уже существует созданный проект, так же из этого раздела производится основная настройка TeamCity (меню справа):
Процесс инициализации проекта состоит из 7 простых шагов, 3 из которых подразумеваются обязательными и их предлагается заполнить с помощью небольшого помощника, рассмотрим каждый по отдельности:
В основных настройках нам потребуется указать только имя проекта, значения всех остальных полей можно оставить по умолчанию:
Следующим шагом является интеграция с системой контроля версий, которая представлена на следующих изображениях. Потребуется указать тип и прочие данные для конфигурации, месторасположение указывайте в корень, все последующие преобразования при получении кода необходимо делать с помощью «Checkout rules», в моем случае достаточно одного простого правила «+:trunk=>source».
Следующий шаг это выбор инструмента для запуска процесса сборки проекта, опять же большую часть часть полей оставим по умолчанию, остальные заполним по аналогии со скриншотами, основной момент на который стоит обратить внимание — в данном примере используется встроенный Apache Ant, но если у вас есть другие предпочтения или опыт — дерзайте. конфигурационный файл будет храниться в SVN, как по по мне так это достаточно удобно.
На следующих четырех скриншотах представленный разделы настройки триггеров, зависимостей, перменных и требований к агентам (агенты и занимаются непосредственно сборкой проекта, в моем случае используется один агент, сконфигурированный по умолчанию при установке, единственное замечания сразу после установки TeamCity требуется подождать некоторое время пока агент придет в готовность.).
Дальше нам нужно создать build.xml который будет управлять процессом сборки (после нескольких дней общения с ним могу сказать что это чудо инструмент который может заменить большую часть небольших shell скриптов для выполнения повседневных действий):
Комитим содержимое в репозиторий, если настроен тригер на комит, то сборка будет запущена автоматически, если нет — нажимаем Run из GUI. Через несколько минут нам будет доступна полная информация о сборке.
Суммарная информация о сборке.
Изменения из репозитория.
Лог процесса сборки.
Артефакты, некоторые из них представленные на следующих скриншотах в виде дополнительных вкладок. к сожалению пока не все результаты удалось красиво интегрировать, но нем не менее можно скачать и просмотреть в изначальном формате.
P. S.
Несмотря на то что хотелось написать статью в виде руководства к действию получился общий обзор, так что если какие-то моменты вам интересны, но не полностью раскрыты — комментируйте, постараюсь раскрыть.
CI TeamCity — Автоматизация build процессов Android и UI тестирования
В этой статье предлагаю Вашему вниманию инструкцию по установке и настройке TeamCity для автоматизации сборки и тестирования Android проектов под Windows.
Также буду уделять внимание особенностям настройки environment’а под Android проект (которые находил в процессе исследования) и различного рода вещам, которые могут помочь облегчить жизнь начинающему тестировщику и разработчику.
При обновлении кода проекта должно происходить:
Основная часть
1. Установка и настройка Java JDK
Вопреки распространенному мнению об установке последней версии Java, JetBrains на своём официальном сайте публикует рекомендованную версию Java SDK: ссылка
Устанавливаем рекомендованную версию: ссылка
Также устанавливаем Environment Variables:
C:\Java\jdk1.8.0_181\bin
Лучше ставить в User variables.
Проверяем правильность установки:
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
Пример: C:\Users\1\AppData\Local\Android\Sdk\platform-tools\ — запуск утилит из консоли нами и CI.
Получаем информацию по актуальной версии и доступных командах:
Пример: C:\Users\1\AppData\Local\Android\Sdk\emulator\ — запуск эмулятора из консоли нами и CI.
Получаем информацию по актуальной версии:
3. Установка Gradle
Gradle входит в Android Studio, но мы поставим еще отдельный для дебага из консоли.
Версия не важна, т.к. подразумевается, что проект будет запускаться через Gradle wrapper.
Предлагаю установить версию аналогично используемой в проекте, например Gradle 3.3. Ссылка.
Также устанавливаем Environment Variables:
GRADLE_HOME – надобности нет, т.к. CI будет использовать Gradle Android Studio.
Актуально для Windows Server, т.к. без него, во время сборки проекта, все выкачанные Gradle библиотеки будут складироваться в C:\Windows\System32\config\systemprofile\.gradle и далее CI не сможет получить доступ к этим файлам.
C:\Gradle\gradle-3.3\bin — путь к папке Gradle для удобного использования из командной строки.
Получаем информацию по актуальной версии:
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
.gradle
.idea
/build/
local.properties
чтобы в VCS не ушли лишние файлики.
4.4. Создаём хранилище ключей (или используем существующий) в папке проекта. Ссылка.
4.5. Добавляем в Gradle ссылки на хранилище ключей, чтобы мы смогли собрать полноценный APK.
4.6. Для проверки работоспособности системы мы соберем новый проект из командной строки. Вводим в CMD:
Переходим в проект.
Ждем завершение сборки.
Если всё хорошо, то получаем результат 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. Создали эмулятор. Проверим его запуск из консоли. Вводим в командной строке:
Обратите внимание, что мы используем функцию /min для запуска эмулятора в фоне. Иначе он бы не дал вводить новые команды в CMD.
Девайс запущен:
4.7.3. Проверяем установку собранного APK.
adb install C:\Users\1\Documents\GitHub\Command2\app\release\app-release.apk
4.7.4. Проверяем запуск установленного APK.
4.7.5. Заливаем проект на удаленный репозиторий, к примеру, на GitHub. Проверяем, будет ли скачиваться проект:
Устанавливаем Git BASH (это если используем Git VCS). Ссылка.
Клонируем проект из удаленного репо. Вводим в консоли Git BASH:
git clone https://github.com/panarik/Command2.git
Видим результат. Проект скопировался в локальную папку:
Всё готово для установки и настройки TeamCity. Почему мы занимаемся упражнениями с командной строкой, а не сразу установкой TeamCity. Гораздо удобнее заранее удостоверится в работоспособности проекта, чтобы в дальнейшем было легче локализовать возможные баги на стадии билда в TeamCity.
5. Установка TeamCity Server и Build Agent
Процесс установки детально прописывать не буду. Он есть в официальном гайде и многих других источниках. Порт сервера TeamCity предлагаю выставить нестандартный, чтобы его было сложнее сканами портов вычислить.
6. Настройка TeamCity Project → Build
В общих настройках нужно лишь задать путь к выводу APK:
6.1. Настройка TeamCity VCS Roots
Все по стандарту. В нашем проекте мы используем Git, поэтому вводим его и ссылку на удаленное репо. Пример:
6.2. Настройка TeamCity Build Configuration
Добавляем Build Step, который будет компилировать проект и выводить APK. В нашем проекте мы используем Gradle.
Вводим в поле Gradle tasks:
Нажимаем Run, получаем APK.
7. Настройка build steps c UI автотестами
Подобрались к самому интересному, а именно, автоматический запуск UI тестов.
7.1. Сначала создадим build step с запуском эмулятора.
Можно сделать URL до BATника полностью, я, для удобства, сделал Environment в TeamCity BAT_FILES c путём к папке с BATниками:
В файле прописываем код запуска эмулятора.
Пример такой команды, который подсмотрел на просторах интернета:
Из UI будет выглядеть так:
Список всех команд на офф сайте: ссылка.
Также из командной строки. Тут всё индивидуально.
7.4. Останавливаем эмулятор.
Также можно отдельным степом сделать выгрузку отчета. По умолчанию он сохраняется в папке с проектом.
Большое спасибо Вам за внимание!
Если у кого-нибудь есть совет по улучшению кода для степов, и предложения по улучшению, буду очень благодарен.
Настройка TeamCity для новичков
Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.
Что такое «непрерывная интеграция», отлично рассказано здесь и вот здесь, повторять эту тему в сотый раз вряд ли нужно.
Ну и для начала – что может TeamCity (далее – просто TC)? А может он следующее: при появлении изменений в указанной ветке репозитория (или ином событии) выполнить сценарий, включающий в себя, например, сборку приложения, прогон тестов, выполнение других сценариев, заливку файлов на удаленный сервер и т.п.
Важным моментом является то, что «сервер интеграции» и «машина, на которой будет проходить этот процесс», – обычно (не обязательно) разные серверы. Более того, машинок, на которых запускаются сборки и тесты, может быть несколько, даже много, и все на разных ОС – в общем, есть, где развернуться.
В связи с этим наш сценарий будет выглядеть так:
А теперь вперёд – реализовывать сценарий!
Забрать свежие изменения из репозитория
Начинается всё с немудрёного создания проекта.
После – создание «build configuration» (конфигурации сборки). Конфигурация определяет сценарий сборки.
На втором же шаге создания конфигурации нас спросят об использованной VCS, так что отвечаем честно, что у нас тут git. У вас может быть другая VCS – не теряйтесь. Добавление нового репозитория производится кнопкой Create and attach new VCS root.
Итак, ключевые настройки:
Далее, нужно настроить автоматический запуск задания. Идём в «Build Triggers» (условия сборки) и выбираем условие VCS Trigger – при настройках по умолчанию он будет раз в минуту проверять наличие новых коммитов в репозитории, а если таковые найдутся – запустит задание на выполнение.
Скомпилировать проект
Поскольку у нас проект на ASP.NET в виде Solution’а из Visual Studio – тут тоже было всё просто.
Идём в меню «Build Steps» (Шаги сборки), выбираем runner type (а их тут действительно много) и останавливаемся на MSBuild. Почему именно на нём? Он даёт достаточно простой способ описать процесс сборки, даже достаточно сложный, добавляя или удаляя различные шаги в простом XML-файле.
Далее всё элементарно.
Build file path – путь к sln-файлу.
MSBuild version, MSBuild ToolsVersion и Run platform выбираем под требования своего проекта.
Если в проекте несколько конфигураций, то можно использовать опцию Command line parameters для ввода примерно такого ключа:
где Production заменить на нужный конфиг.
Включить скачивание NuGet-пакетов
Важный пункт, в случае если вы используете NuGet-пакеты; если нет – можно переходить сразу к следующему пункту.
Поскольку NuGet-пакеты весят немало, да и хранить в репозитории бинарники библиотек без особой необходимости не хочется, можно использовать замечательную опцию NuGet Package Restore:
В этой ситуации бинарники библиотек в репозиторий не включаются, а докачиваются по мере необходимости в процессе сборки.
Но MSBuild – настоящий джентльмен и не будет без разрешения делать лишних телодвижений, поэтому и докачивать пакеты просто так не будет – ему сей процесс нужно разрешить. Для этого придется либо на клиенте установить переменную окружения Enable NuGet Package Restore в значение true, либо пойти в меню Build Parameters и выставить его там.
Прогнать юнит-тесты
У нас юнит-тесты являются отдельным проектом внутри решения. Так что на предыдущем шаге они уже скомпилированы – осталось их запустить.
%teamcity.build.checkoutDir% – это переменная, указывающая на папку, в которую скачиваются данные из репозитория. В принципе, она не обязательна для указывания, т.к. по умолчанию путь идёт именно относительно этой директории, поэтому путь можно было бы сократить до:
Отдельно отмечу опцию Run recently failed test first – если в предыдущем прогоне какие-то тесты упали, то в следующем запуске первыми запустятся именно они, и вы быстро узнаете об успешности последних изменений.
Прогнать тесты интерфейса (функциональные тесты)
Здесь все гораздо интереснее, чем с юнит-тестами. Кэп тут подсказывает, что, чтобы протестировать проект в браузере, его, т.е. проект, необходимо запустить. Но тут мы схитрили, запуская веб-сервер прямо из кода тестов Selenium:
А сам запуск выглядит абсолютно точно так же, как на шаге с юнит-тестами.
Залить изменения на тестовый сервер
Сервер, на котором находится агент TC, и сервер, на котором установлен IIS, – разные серверы, причем, более того, находятся они в разных сетях. Поэтому файлы нужно как-то на конечный сервер доставить. И вот тут решение выбрано, может, не очень элегантное, зато крайне простое. Используем заливку через FTP, причем делает сие за нас MSBuild.
А так – задание по его вызову:
Недостаток решения – заливаются ВСЕ файлы, а не только новые изменившиеся. На проекте с кучей файлов верстки или множеством модулей это может стать проблемой из-за затрачиваемого на заливку времени.
Ещё один замеченный недостаток – при встрече файла с нелатиницей в названии падает с ошибкой. Латиница и буквы/цифры обрабатываются нормально. Ноги этой проблемы, похоже, растут из специфики протокола FTP: тот основан на ASCII, но, как именно кодировать не ASCII-символы, он не описывает, предлагая «делать так, как будет понимать ваш сервер». Соответственно, чтобы вылечить проблему, не меняя схему, нужно пропатчить MSBuild Community Tasks, благо, исходники открыты. Ну, или воспользоваться альтернативным способом заливки файлов, например через WinSCP.
Остановка и запуск сервера для релизного сценария
Мы её решаем чуть диким, но симпатичным способом. У IIS’а есть особенность: если в корень сайта положить файл с именем app_offline.html, то сайт отрубается, при обращении ко всем файлам будет выдаваться содержимое этого файла.
Минус – обращение именно что КО ВСЕМ файлам, включая статичные. Так что, если хочется сделать заглушку с оформлением, CSS и картинками, используйте инлайн-стили и data:url, ну, или как вариант – выложите их на отдельном сервере.
Включаем-отключаем мы сервер через WinSCP-сценарий и такие вот файлики:
TeamCity: настраиваем CI/CD в вашей команде
TeamCity — пожалуй, один из самых популярных CI/CD-серверов, который используют разработчики по всему миру. В этой статье я расскажу про базовые концепции, на которых он построен, и на примерах покажу, как можно настроить CI/CD в вашей команде.
Build Agent
Перед тем как начать разбираться в TeamCity, стоит понять, как в нем построен процесс сборки и выполнения CI/CD задач.
В TeamCity есть такое понятие, как build agent — это какая-то машина, на которой происходит процесс сборки. Единовременно агент может выполнять всего одну сборку.
Сборка проходит в несколько шагов:
После некоторого события, которое было поймано триггером сборки (build trigger), сборка попадает в очередь и будет начата сразу, как только появится свободный агент.
Начинается сборка, которая поочередно выполняет все шаги сборки (build steps), которые были указаны в конфигурации (build configuration).
Сборка заканчивается, и ее результаты сохраняются в истории конфигурации.
Project
Один из основных концептов в TeamCity — проект, именно он содержит в себе так называемые конфигурации сборки (build configurations), которые и выполняют нужные нам задачи (запуск автотестов, линт-проверок и других суперважных и полезных вещей).
Проекты могут быть вложены друг в друга и принимать древовидную структуру.
Здесь мы видим, что проект Android имеет вложенную в него конфигурацию Pull Requests, а также два проекта: AutoTests Checker и Publish Pipeline
Настройки проекта
У проекта есть множество настроек и параметров, к которым можно перейти, кликнув на название проекта и нажав Edit project в правом верхнем углу. Не у всех есть доступ к настройкам, так что, если он вам нужен, обращайтесь к людям, отвечающим за CI/CD в вашей команде.
Давайте разберем самые важные настройки.
General Settings
Здесь мы видим следующее:
Уникальный ID, который потом можно будет использовать в REST API
Все настройки и параметры (о них мы поговорим позже), которые были заданы в проекте, распространяются на все вложенные в этот проект подпроекты.
Под этими настройками мы видим список конфигураций сборки (build configurations) — о них тоже поговорим чуть позже.
VCS Roots
Здесь содержится набор настроек и правил, нужных для того, чтобы TeamCity мог подключиться к вашей системе контроля версий. При добавлении нового VCS Root он становится доступен внутри всех конфигураций, которые содержатся в проекте.
Для «соединения» TeamCity с системой контроля версий необходимо указать следующие параметры:
Тип системы контроля версий (например, Subversion или Git)
Уникальное имя нового рута
Уникальный ID рута, который затем может использоваться в REST API
URL до репозитория в формате https://, ssh://git@
Основная ветка, изменения которой будет «отлавливать» TeamCity
Далее нужно указать способ авторизации. Это может быть пароль или приватный ключ. На наших агентах установлены ключи, поэтому выбран default private key.
Крайне рекомендую на каждый репозиторий заводить всего лишь один VCS Root.
Parameters
Для изменения поведения билда можно использовать параметры TeamCity.
Некоторые из них позволяют передать настройки непосредственно в процесс, в котором идет билд. Другие служат для подстановки настроек, например в build steps.
Параметры можно использовать при сборке, они делятся на три категории:
Параметры окружения (env.)
Передаются в окружение процессу, в котором стартуется билд, и в дальнейшем их можно будет использовать в конфигурациях сборки
Системные параметры (system.)
Используются раннерами сборки (build runners) и автоматически передаются в них.
Например, в случае с Gradle любая переменная, указанная в system., будет передана в gradle.properties, но без префикса system.
Эти параметры не передаются в сборку, к ним можно только обращаться из конфигураций сборки. TeamCity делает подстановку параметра через %param_name% в полях, отмеченных специальным значком
Итак, мы поняли, чем параметры отличаются друг от друга: системные передаются автоматически в систему сборки (gradle, например), параметры конфигурации можно только считывать, обратившись к ним по ссылке, а параметры окружения добавляются в окружение процесса и доступны на всех шагах сборки.
Теперь поговорим о создании параметров.
Создание параметров
Здесь все очень просто:
Нажимаем на Add new parameter на вкладке с параметрами. В появившемся окне видим несколько полей, которые необходимо заполнить:
Тип параметра (environment, system, configuration)
Значение параметра, в нем можно ссылаться на другие параметры в формате %parameter_name%
Самое интересное поле.В нем можно настроить тип параметра, его видимость, ограничить его редактирование, добавить к нему описание и сделать его обязательным для указания
Parameter spec
Здесь мы можем настроить следующее:
Метка параметра, которая поясняет, зачем этот параметр вообще нужен
Описание параметра, которое будет видно при мануальном запуске сборки
Normal, Hidden (его не будет видно при мануальном запуске сборки), Prompt — этот параметр обязательно нужно будет указывать при запуске сборки
Параметр нельзя будет изменять в течение сборки
Интересное поле: можно указать password — и тогда значение поля будет скрыто от всех пользователей. Полезно для всяких паролей и хуков
Build Configurations
Мы разобрались, что такое проект, как его «соединять» с системой контроля версий, как добавлять параметры в сборку. И теперь, думаю, можно обсудить самое важное: как эту сборку вообще конфигурировать и запускать?
Итак, конфигурация сборки — это набор правил, которые определяют сценарий сборки. Каждая сборка, которая была выполнена по заданному сценарию, может иметь два статуса: Success либо Failed.
Правила, по которым сборка заканчивается с ошибкой, можно настроить — об этом мы поговорим позже. Все сборки в заданной конфигурации попадают в Build Configuration Home, где можно отслеживать их статус.
Как обычно это происходит в TeamCity — все нужно настраивать, и конфигурации сборки не являются исключением. Нажимаем на Edit Configuration в правом верхнем углу и видим список настроек:
Давайте подробнее остановимся на самых важных пунктах.
General Settings
Здесь мы видим список обязательных для заполнения полей, а именно:
Уникальное имя конфигурации (например, Development, Upload To Testers, Nightly Builds)
Build Configuration ID
Уникальный ID конфигурации, который можно будет использовать в REST API
Build number format
Каждой сборке TeamCity присваивает свой номер. В этом поле его можно отформатировать. Например, выводить не «1984», а «какая-нибудь-строка-1984»
После каждой сборки TeamCity может оставлять артефакты (подробнее о них расскажу позже), здесь мы прописываем пути к ним.
Например, все, что будет лежать в */build/reports/, TeamCity заберет к себе и сохранит в конфигурации в качестве артефакта. А все, что лежит в rko/build/outputs/apk, TeamCity поместит в отдельную папку apk и также отдаст нам ее содержимое в качестве артефакта
Version Control Settings
Конфигурации сборки тоже нужно «соединить» с системой контроля версий. Здесь все происходит по тем же правилам, что и в проекте.
На скриншоте видно, что VCS Root был унаследован (inherited) у того, что мы создали в настройках проекта (Mobile Bank For Business), к которому относится данная конфигурация.
Таким образом, эта конфигурация может взаимодействовать с веткой dev.
Build Steps
Вот мы и подобрались до самой интересной и важной части всех конфигураций сборки — к месту, в котором поочередно выполняются все нужные нам вещи (сборки приложений, прогон lint-проверок, прогоны тестов и так далее), — шагам сборки (build steps).
Настройки каждого шага сборки индивидуальны в зависимости от раннера, поэтому давайте выберем самый популярный раннер — командную строку — и посмотрим, как создать с ним шаг сборки.
Нажимаем Add build step на вкладке Build Steps.
Далее видим следующую страницу:
В качестве Runner type выбираем Command Line:
Здесь мы видим, что нам нужно указать Step name — имя шага сборки, благодаря которому мы будем понимать, на каком этапе находится сборка. Давайте назовем его Hello, World.
Далее мы видим Execute step — это поле позволяет настроить условия, при которых данный шаг будет выполнен. По умолчанию там стоит If all previous steps finished successfully, однако нам есть из чего выбрать:
Далее мы видим настройку Run, в которой можно выбрать либо Custom Script (туда прямо можно запихнуть код на bash), либо Executable with parameters, сказав TeamCity, что мы хотим запустить скрипт, который уже лежит где-то в проекте, который он зачекаутил.
Давайте выберем Custom Script, а внутрь поместим следующее:
С другими типами раннеров все примерно так же.
Передача параметров в шаги сборки
Давайте создадим какой-нибудь параметр внутри конфигурации, которую мы рассматривали ранее, и попробуем передать его в шаг сборки. Открываем вкладку Parameters в настройках конфигурации, нажимаем Add new parameter и заполняем поля:
Так как мы не собираемся его нигде менять и запихивать в окружение, обозначим, что это параметр конфигурации, и назовем его cool_parameter.
Нажимаем Save, идем на вкладку Build Steps и нажимаем на шаг сборки Hello, World, который создали до этого, и добавляем в скрипт следующее:
Завернув название параметра в “%”, TeamCity сможет обращаться к нему и считывать.
Артефакты
Еще одна интересная фича в TeamCity — артефакты. Это все те файлы, которые были получены в результате сборки: файлы с логами, WAR-файлы и так далее.
Ранее, настраивая конфигурацию сборки, мы уже видели поле, в котором нужно было прописать путь к артефактам. Давайте остановимся на них подробнее.
Мы не хотим прогонять lint вручную, потому что он занимает много времени, и решаем автоматизировать его запуск. Допустим, у нас уже создан проект и конфигурация сборки.
Открываем General Settings проекта и находим поле Artifact paths. Прописываем там следующее:
Таким образом, все, что будет лежать в папке lint, TeamCity добавит в артефакты сборки, которые будут доступны после того, как она завершится.
Далее нужно добавить шаг сборки, который будет прогонять lint. Настройки этого шага зависят от раннера.
Agent Requirements
Еще одна важная настройка каждой конфигурации — Agent Requirements.
С ее помощью мы можем сказать TeamCity, на каких агентах он может запускать конфигурацию. Например, чтобы наш агент мог собирать Android-проекты, мы можем потребовать, чтобы в переменных окружения этого агента обязательно был указан ANDROID_HOME.
Или, чтобы запускать bash-скрипты, мы можем потребовать, чтобы ОС агента была только Linux. Agent Requirements можно наследовать из проекта или для каждой конфигурации создавать свои.
Промежуточные итоги
Итак, давайте закрепим несколько важных моментов, которые мы только что прошли:
TeamCity состоит из проектов, каждый из которых может содержать в себе вложенные проекты или конфигурации сборки.
Если мы хотим что-то запустить (линт-проверки, тесты, какие-нибудь скрипты), нужно создать конфигурацию сборки.
Каждая конфигурация состоит из шагов сборки (build steps).
Шаги сборки настраиваются с помощью раннеров сборки (build runners).
Взаимодействие с системой контроля версий происходит через VCS roots.
Информацию об окружающем мире TeamCity забирает из параметров.
Каждая сборка может оставлять после себя артефакты.
О Pipeline и Build Chains
Давайте теперь затронем несколько более сложные и важные вещи, освоив которые можно самостоятельно настраивать взаимодействие конфигураций сборки между разными проектами, а также работать с артефактами.
Итак, конфигурация сборки состоит из шагов сборки (build steps), которые выполняются в рамках одного билда. Ты можешь добавить в одну конфигурацию сколько угодно шагов, но это плохая практика. Пихать большое количество шагов в одну конфигурацию — большая ошибка, и если ты все-таки ее совершил, имеет смысл задуматься: может, одна конфигурация берет на себя слишком много всего?
Но что делать, если ты понял, что шагов действительно много, причем некоторые из них независимы друг от друга и могут запускаться параллельно, что существенно ускорило бы твой билд? К счастью, для решения этой проблемы TeamCity дает нам простой механизм прямо «из коробки» — build chains!
Но прежде чем я расскажу про этот механизм, давай введем несколько других определений, которые помогут погрузиться в тему.
Pipeline
Здесь все довольно просто. Пайплайн — это некоторый (последовательный) набор действий, совершаемых во время сборки. И хотя пайплайн — это классическое определение для процессов, происходящих на CI/CD, нигде — ни в документации TeamCity, ни в веб-интерфейсе — ты не встретишь это слово.
Дело в том, что у TC есть собственный термин — build chain, цепочка сборки. Цепочка сборки в TeamCity представляет собой направленный ациклический граф, поэтому пайплайн, подразумевающий последовательное выполнение шагов, — лишь частный случай цепочки сборки из TC.
Пример направленного ациклического графа
Но кроме того, что шаги в цепочках сборки не всегда могут быть последовательными, есть и другие отличия от стандартного пайплайна, о которых расскажу чуть позже.
Snapshot Dependencies
Еще один термин, который я введу, — снепшот-зависимость. Это как раз то, что позволяет нам связать между собой две конфигурации.
Устанавливая снепшот-зависимость для какой-нибудь сборки (например, сборки B) от другой сборки (сборки A), ты можешь быть уверен в том, что сборка B запустится только после того, как будет запущена и завершена та сборка, от которой она зависит (сборка А).
Простыми словами: если в сборку B добавить снепшот-зависимость на сборку A, то B будет запускаться только после того, как запустится и завершится сборка А. Сборка B в этом случае называется зависимой.
Обрати также внимание на слово «снепшот» — это про синхронизацию исходников. При использовании таких зависимостей все они будут запускаться на одной ревизии VCS root (или на ревизиях, сделанных в одно время в разных VCS).
Snapshot dependencies формируют тот самый ациклический граф, о котором мы говорили ранее, а это не что иное, как цепочка сборки.
Build Chains
Наконец-то мы добрались до самих цепочек сборки — build chains.
Как я уже говорил, build chains позволяет разносить шаги сборки по разным конфигурациям, связывая их при помощи снепшот-зависимостей.
То, как TeamCity работает с цепочками сборки, открывает для нас несколько интересных фичей: параллельная сборка конфигураций (круто, да?), переиспользование результатов сборки, синхронизация конфигураций между разными репозиториями. Но самое главное: build chains существенно облегчают поддержку и развитие конфигураций.
Чтобы создать цепочку сборки, достаточно выбрать две конфигурации сборки и настроить между ними снепшот-зависимость. В качестве примера возьмем две конфигурации:
Одна будет собирать релизный apk-файл с android-приложением мобильного банка для юридических лиц.
Вторая будет отправлять этот apk на сервер Bishop — сервиса для проверки android-приложений на наличие уязвимостей.
Итак, открываем конфигурацию сборки Bishop-scan:
Переходим на вкладку Dependencies и нажимаем кнопку Add new snapshot dependency:
Как видим, кроме snapshot dependency можно добавить artifact dependency, но об этом мы поговорим несколько позже.
В появившемся окне нам предстоит настроить зависимость, указав несколько настроек:
Выбираем ту конфигурацию, от которой будет зависеть текущая
Enforce revisions synchronization
Если включить эту опцию, все конфигурации будут работать, используя одни и те же сорсы, и никакие изменения в репозитории, возникшие на момент запуска зависимого билда, не будут браться в расчет
Do not run build if there is a suitable one
С этой опцией TeamCity не будет запускать зависимую сборку, если существует другая запущенная или завершенная подходящая (suitable) сборка. О том, что такое suitable build, мы поговорим чуть позже
Run build on the same agent
TeamCity будет собирать зависимую сборку на том же агенте, на котором собиралась основная сборка
Only use successful builds from suitable ones
Из suitable-билдов будут использоваться только те, которые были завершены без ошибок
On failed dependency/ On failed to start/canceled dependency
Здесь указываем, что делать, если зависимый билд упал: игнорировать, сообщать об ошибке, отменять билд
Нажимаем Save и вуаля — мы успешно построили свой первый build chain!
Полный граф цепочки сборки можно посмотреть, нажав на build chain тут:
Откроется отдельная вкладка, которая визуализирует для нас этот граф:
По графу видно, что перед тем, как мы запустим Bishop-scan, сначала будет собран Development, а только потом запустится Bishop-scan. Круто? Конечно!
Но вот проблема: Development собирает для нас артефакт. Как его использовать в Bishop-scan?
Artifact Dependencies
Все просто: кроме зависимости от конфигурации сборки мы можем зависеть и от артефактов, которые конфигурация сборки генерирует.
Конкретно в моем примере мне нужно будет забрать apk-файл, который был собран при сборке Development. Для этого снова идем во вкладку Dependencies конфигурации Bishop-scan:
Нажимаем на Add new artifact dependency:
В появившемся окне указываем следующие настройки:
У какой конфигурации мы будем забирать артефакт?
Get artifacts from
Откуда будем брать этот артефакт? Можем выбрать несколько вариантов:
из этой же цепочки (тогда ждем, когда зависимый билд соберется);
из последней успешной сборки, из последней сборки, из последней закрепленной сборки и из сборки с определенным номером
Путь к артефакту. Очень удобно его указать, нажав на «веточку» справа. После «→» мы указали путь к environment-переменной, в которую положили этот apk
Стоит также обратить внимание на то, что зависимая конфигурация сборки (Development) должна объявить у себя в настройках, что этот артефакт она отдает.
Для этого идем в настройки Development и в графе Artifact Paths указываем путь к этому артефакту:
Теперь все, что лежало в rko/build/outputs/apk, будет перемещено в папку apk в артефактах, сгенерированных этой конфигурацией.
И все! Мы успешно связали между собой две конфигурации.
Теперь перед каждым запуском Bishop-scan сначала будет собираться Development, а только потом — Bishop-scan, использующий артефакт, полученный на предыдущем шаге.
Но что, если мы хотим как-то по-особому настроить правила запуска конфигурации в цепочке сборки?
Build Triggers
Снова открываем настройки конфигурации Bishop-scan и нажимаем на вкладку Triggers:
Здесь нажимаем Add new trigger и в появившемся окне видим следующее:
Запускаем билд только тогда, когда TeamCity обнаружил какое-то изменения в содержимом VCR Root’а
Запускаем билд точно по расписанию (можно указать любые промежутки времени между билдами)
Finish Build Trigger
Запускаем билд только тогда, когда закончился билд какой-то определенной конфигурации (по сути, это частный случай нашей цепочки сборки, состоящей из двух конфигураций)
Допустим, мы хотим, чтобы сборка в Bishop отсылалась всегда, когда в VCS Root’е Development произошло какое-либо изменение. Для этого выбираем VCS Trigger и в появившемся окне нажимаем на Trigger a build on changes in snapshot dependencies:
В нашем примере две конфигурации сборки, однако понадобится лишь один VCS Trigger. Все потому, что мы можем сказать триггеру, чтобы он отслеживал изменения в каждой из конфигураций, когда находится в цепочке сборки.
Таким образом, если хотя бы в одной из них происходит изменение, TeamCity запускает целую цепочку. Ставить триггер нужно на последнюю конфигурацию цепочки, и тогда ТС сам запустит все билды из нее.
Checkout Rules
Вообще, существует довольно много способов оптимизировать пайплайн. Один из них — настроить правила, по которым TeamCity скачивает репозиторий.
Для этого можно правильно настроить Checkout Rules в конфигурации Development.
Открываем Version Control Settings и жмем на Edit checkout rules:
Переиспользование результатов сборки
Еще один способ оптимизировать пайплайн — переиспользование артефактов. Допустим, цепочка сборки успешно завершилась и мы запустили ее снова (или она сама запустилась по какой-либо причине), но на этот раз TeamCity будет немного хитрее.
Что, если мы не будем пересобирать конфигурацию зависимости в цепочки, если никаких изменений в кодовой базе не было? Действительно, возвращаясь к нашему примеру, вряд ли нужно каждый раз собирать apk на Development, если на самом деле там ничего не изменилось.
К счастью, чтобы все работало именно так, не нужно ничего делать: все работает прямо «из коробки». Но мы можем ее отключить.
Заходим в Build Configuration Home нашего Bishop-scan:
Нажимаем на многоточие, которое находится рядом с Run. В появившемся окне переходим на вкладку Dependencies, нас интересует настройка Rebuild snapshot dependencies:
Нажимаем Run Build, и вуаля — теперь TC заново соберет артефакты в цепочке, даже если не было никаких изменений в кодовой базе.
Параллельный запуск конфигураций
И вот мы добрались до самой интересной и важной фичи, которую даруют нам цепочки сборки, — параллельный запуск.
Допустим, у нас в пайплайне добавилось еще две конфигурации, которые совсем не зависят друг от друга, а значит, могут выполняться параллельно. Обе эти конфигурации в зависимостях имеют снепшот-зависимость на Bishop-scan.
Помните, я говорил, что build chain — ациклический граф?
Так вот, сейчас самое время подумать, почему цепочки были спроектированы именно так: независимые ноды графа могут обрабатываться параллельно при наличии ресурсов для их обработки (то есть билд-агентов).
TeamCity сам позаботится о параллельной сборке независимых конфигураций и настраивать руками ничего не нужно.
Но что теперь делать с триггером сборки? В прошлый раз мы выставляли его на Bishop-scan, а сейчас что, придется добавить еще два — на каждую из новых конфигураций?
Можно, но есть более удобное решение: Composite Build.
Composite Build
Еще одна классная фича в TC — композитная конфигурация сборки.
Ее задача заключается в том, чтобы агрегировать результаты сборки других конфигураций, от которых она зависит. А самое крутое, что, создавая такую конфигурацию, нам не нужно отводить место под еще один агент сборки — он просто не нужен.
Создание такой конфигурации отличается от обычной лишь одной настройкой:
В поле Build configuration type необходимо выбрать Composite, а далее просто добавить снепшот-зависимости на наши новые конфигурации.
Далее добавляем две конфигурации в зависимости нашего композитного билда:
Добавляем Generate Build Number и Bishop-scan в зависимости и смотрим итоговый граф:
Вуаля! Теперь эта конфигурация будет частью нашей цепочки сборки, и мы сможем настроить лишь один триггер — на нее.
Заключение
Итак, мы с ознакомились с основными вещами, с которыми сталкивается каждый разработчик, настраивая CI/CD в своей команде:
Настройка конфигураций сборки
Взаимодействие конфигураций сборки между собой
Параллельный запуск конфигураций сборки
Надеюсь, статья окажется вам полезной!
Кстати, недавно у команды Тинькофф.Бизнес появился свой Telegram-канал, в котором мы рассказываем о наших процессах и технических решениях, подписывайтесь!