TeamCity Research
Одна из главных особенностей - все настраивается через интерфейс (нет конфигов как в gitlab-ci)
Судя по всему проще от этого не становится
Архитектура такая же как в gitlab-ci
Есть сервер и агенты
Насколько понимаю бесплатно можно сделать до 3-х агентов, хочешь больше трех - плати
Агент называется - Build Agent
Один агент - одна сборка (нельзя как в gitlab-ci запустить на одном раннере несколько джоб)
Сборка проходит в несколько шагов:
- После некоторого события, которое было поймано триггером сборки (build trigger), сборка попадает в очередь и будет начата сразу, как только появится свободный агент
- Начинается сборка, которая поочередно выполняет все шаги сборки (build steps), которые были указаны в конфигурации (build configuration)
- Сборка заканчивается, и ее результаты сохраняются в истории конфигурации
Один из основных концептов в TeamCity — проект, именно он содержит в себе так называемые конфигурации сборки (build configurations), которые и выполняют нужные нам задачи (запуск автотестов, линт-проверок и других суперважных и полезных вещей)
Проекты могут быть вложены друг в друга и принимать древовидную структуру
конфигурация сборки — это набор правил, которые определяют сценарий сборки. Каждая сборка, которая была выполнена по заданному сценарию, может иметь два статуса: Success либо Failed
Есть настройка Agent Requirements
С ее помощью мы можем сказать TeamCity, на каких агентах он может запускать конфигурацию. Например, чтобы наш агент мог собирать Android-проекты, мы можем потребовать, чтобы в переменных окружения этого агента обязательно был указан ANDROID_HOME
Еще одна интересная фича в TeamCity — артефакты. Это все те файлы, которые были получены в результате сборки: файлы с логами, WAR-файлы и так далее
- TeamCity состоит из проектов, каждый из которых может содержать в себе вложенные проекты или конфигурации сборки
- Если мы хотим что-то запустить (линт-проверки, тесты, какие-нибудь скрипты), нужно создать конфигурацию сборки
- Каждая конфигурация состоит из шагов сборки (build steps)
- Шаги сборки настраиваются с помощью раннеров сборки (build runners)
- Взаимодействие с системой контроля версий происходит через VCS roots
- Информацию об окружающем мире TeamCity забирает из параметров
- Каждая сборка может оставлять после себя артефакты
В TeamCity есть пайплайны, но называются они - build chains
снепшот-зависимость - это как раз то, что позволяет нам связать между собой две конфигурации
Устанавливая снепшот-зависимость для какой-нибудь сборки (например, сборки B) от другой сборки (сборки A), ты можешь быть уверен в том, что сборка B запустится только после того, как будет запущена и завершена та сборка, от которой она зависит (сборка А)
Artifact Dependencies
Все просто: кроме зависимости от конфигурации сборки мы можем зависеть и от артефактов, которые конфигурация сборки генерирует
Триггеры позволяют запускать билды при определенных событиях:
| name | description |
|---|---|
| VCS Trigger | Запускаем билд только тогда, когда TeamCity обнаружил какое-то изменения в содержимом VCR Root'а |
| Schedule Trigger | Запускаем билд точно по расписанию (можно указать любые промежутки времени между билдами) |
| Finish Build Trigger | Запускаем билд только тогда, когда закончился билд какой-то определенной конфигурации (по сути, это частный случай нашей цепочки сборки, состоящей из двух конфигураций) |
Вообще, существует довольно много способов оптимизировать пайплайн. Один из них — настроить правила, по которым TeamCity скачивает репозиторий
Что, если мы не хотим, чтобы изменение в каком-нибудь .gradle-файле влекло за собой полную сборку .apk и анализ ее на серверах Bishop?
Для этого достаточно прописать -:gradle в правилах, и папка gradle будет игнорироваться при мониторинге VCS Root'а
Переиспользование результатов сборки
Еще один способ оптимизировать пайплайн — переиспользование артефактов. Допустим, цепочка сборки успешно завершилась и мы запустили ее снова (или она сама запустилась по какой-либо причине), но на этот раз TeamCity будет немного хитрее
Что, если мы не будем пересобирать конфигурацию зависимости в цепочки, если никаких изменений в кодовой базе не было? Действительно, возвращаясь к нашему примеру, вряд ли нужно каждый раз собирать apk на Development, если на самом деле там ничего не изменилось
К счастью, чтобы все работало именно так, не нужно ничего делать: все работает прямо «из коробки». Но мы можем ее отключить
Независимые билды автоматом будут выполняться параллельно
Есть композитные конфигурации сборки. Они нужны чтобы агрегировать результаты сборки других конфигураций, от которых она зависит
Есть возможность не просто клацать мышкой, а описывать конфигурации через файлы
Но для этого нужно освоить Kotlin DSL
Installation
Устанавливаем docker
https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository
Есть вот такой композник
https://github.com/JetBrains/teamcity-docker-samples/blob/master/compose-ubuntu/docker-compose.yml
В этом компознике стоит версия PostgreSQL - 'latest'
С ней не работает
Надо понизить до 14.10
root@teamcity-server:~/teamcity-docker-samples/compose-ubuntu# git diff docker-compose.yml
diff --git a/compose-ubuntu/docker-compose.yml b/compose-ubuntu/docker-compose.yml
index 641f767..847b474 100644
--- a/compose-ubuntu/docker-compose.yml
+++ b/compose-ubuntu/docker-compose.yml
@@ -11,7 +11,7 @@ version: '3.1'
services:
db:
- image: postgres:latest
+ image: postgres:14.10
restart: always
environment:
- POSTGRES_PASSWORD=teamcity_password
Запускаем сервисы db и teamcity (в моем случае запускаю только их потому что агенты будут на других серверах)
root@teamcity-server:~/teamcity-docker-samples/compose-ubuntu# docker compose up -d db
[+] Running 15/15
✔ db 14 layers [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 0B/0B Pulled 11.3s
✔ af107e978371 Already exists 0.0s
✔ a726894d830e Pull complete 0.5s
✔ 1c21c16fd9d7 Pull complete 0.7s
✔ 521a66cbf5a2 Pull complete 0.5s
✔ 4abf98c2ddd3 Pull complete 1.1s
✔ f6cc9552931a Pull complete 1.1s
✔ 443cdb0b30fa Pull complete 1.2s
✔ e9219d8c9383 Pull complete 1.6s
✔ c625ef496de6 Pull complete 3.2s
✔ 9caa61a75372 Pull complete 1.7s
✔ de07da787140 Pull complete 2.0s
✔ a843a63a7b37 Pull complete 2.2s
✔ c934d807fbdb Pull complete 2.5s
✔ 8ae0ca2fd85a Pull complete 2.7s
[+] Running 2/2
✔ Network compose-ubuntu_default Created 0.1s
✔ Container compose-ubuntu-db-1 Started 13.6s
root@teamcity-server:~/teamcity-docker-samples/compose-ubuntu# docker compose up -d teamcity
[+] Running 15/15
✔ teamcity 14 layers [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 0B/0B Pulled 135.5s
✔ 345e3491a907 Pull complete 1.0s
✔ 57671312ef6f Pull complete 0.5s
✔ 5e9250ddb7d0 Pull complete 0.5s
✔ 6bbef3197475 Pull complete 1.5s
✔ 7c5cfc9452f6 Pull complete 6.5s
✔ 34da59a6706c Pull complete 1.6s
✔ b4af7cab8c7a Pull complete 3.6s
✔ bc61f7600fe6 Pull complete 2.3s
✔ f6e6add133f4 Pull complete 3.1s
✔ edc84f56b70c Pull complete 3.9s
✔ 8a95dbe0f3d1 Pull complete 4.2s
✔ 7653d2dca89a Pull complete 4.4s
✔ ca60eea73724 Pull complete 48.0s
✔ f956277739bb Pull complete 5.7s
[+] Running 2/2
✔ Container compose-ubuntu-db-1 Running 0.0s
✔ Container compose-ubuntu-teamcity-1 Started 0.7s
Все запустилось
root@teamcity-server:~/teamcity-docker-samples/compose-ubuntu# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c192767bc281 jetbrains/teamcity-server:2021.1 "/run-services.sh" 32 seconds ago Up 31 seconds 0.0.0.0:8112->8111/tcp, :::8112->8111/tcp compose-ubuntu-teamcity-1
16157e33f843 postgres:14.10 "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 0.0.0.0:5433->5432/tcp, :::5433->5432/tcp compose-ubuntu-db-1
Открываем в браузере - что-то грузится
Далее на одном сервере поднимаю agent-1
А на втором agent-2
Для этого правим адрес TeamCity сервера
root@teamcity-agent-1:~/teamcity-docker-samples/compose-ubuntu# git diff
diff --git a/compose-ubuntu/agents/agent-1/conf/buildAgent.properties b/compose-ubuntu/agents/agent-1/conf/buildAgent.properties
index 9657e08..fc4e84e 100644
--- a/compose-ubuntu/agents/agent-1/conf/buildAgent.properties
+++ b/compose-ubuntu/agents/agent-1/conf/buildAgent.properties
@@ -1,6 +1,6 @@
name=Agent 1-2
ownPort=9090
-serverUrl=http\://teamcity\:8111
+serverUrl=http\://158.160.120.45\:8112
workDir=../work
tempDir=../temp
И запускаем
root@teamcity-agent-1:~/teamcity-docker-samples/compose-ubuntu# docker compose up -d teamcity-agent-1
[+] Running 15/15
✔ teamcity-agent-1 14 layers [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 0B/0B Pulled 93.3s
✔ 345e3491a907 Pull complete 0.8s
✔ 57671312ef6f Pull complete 0.5s
✔ 5e9250ddb7d0 Pull complete 0.5s
✔ dc0f325b53bd Pull complete 1.7s
✔ fc97a4505ec9 Pull complete 3.9s
✔ 1bb35b27825e Pull complete 1.4s
✔ 53c7680f2f2d Pull complete 2.4s
✔ 6f4277dd04e3 Pull complete 2.4s
✔ 8b1abdca0c3b Pull complete 13.3s
✔ 0b7bba204b0d Pull complete 3.5s
✔ 3bd66f619fea Pull complete 4.1s
✔ f0a9f407a3a4 Pull complete 4.8s
✔ 7d0ffb89eeca Pull complete 24.7s
✔ e87378a0beaf Pull complete 5.9s
[+] Running 2/2
✔ Network compose-ubuntu_default Created 0.2s
✔ Container compose-ubuntu-teamcity-agent-1-1 Started 32.6s
Дальше они появятся на вкладке Agents > Unauthorized
Авторизуем их и они переходят на вкладку Connected
First Pipeline
Попробуем наладить CI
Сперва нужно создать проект в TC
При создании проекта он спросит репу
Я создал тестовую репу и выписал в ней Access Token для TC
Ниже скрин как подключить репу к TC
После создания проекта в нем уже будет добавлен VCS Trigger, то есть TC из коробки отлеживает изменения в репозитории
Но мы настроим интеграцию со стороны gitlab чтобы TC реагировал сразу после коммита (по умолчанию он пуллит репозиторий ежеминутно)
Сперва нужно создать пользователя в TC (Administration > Users) - я своего назвал gitlab-test
И добавляем интеграцию (Build Type это Build configuration ID)
Теперь гитлаб триггерит TeamCity чтобы тот запустил билд
Но мы хотим видеть статус билда в гитлабе (как с gitlab-ci)
Для этого идем в настройки билда (джобы) и добавляем в разделе Build Features плагин Commit status publisher (для него я выписал отдельный токен в репе)
Вот результат
No Comments