TeamCity

TeamCity — це CI/CD-сервер від компанії JetBrains, який використовується для автоматизації збірки, тестування, перевірки якості коду, публікації артефактів і розгортання програмного забезпечення.

TeamCity застосовується у Java, .NET, Kotlin, JavaScript, Python, Android, Docker, мікросервісних, backend, frontend, mobile, SaaS та корпоративних проєктах. JetBrains описує TeamCity як CI/CD-сервер, а його build-система складається із сервера та build agents. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))

Важливо: TeamCity — це не IDE і не система контролю версій. Це сервер автоматизації CI/CD, який отримує код із Git або іншої VCS, запускає збірку, тести, перевірки, створює артефакти та може виконувати deployment.

Загальний опис

TeamCity допомагає командам автоматизувати процес розробки. Коли розробник надсилає зміни в репозиторій, TeamCity може автоматично запустити збірку, виконати тести, перевірити код, створити артефакт і повідомити команду про результат.

У типовому процесі TeamCity підключається до репозиторію коду, наприклад Git, GitHub, GitLab, Bitbucket або іншої системи контролю версій. Після появи нових змін CI/CD-сервер запускає потрібні build configurations на build agents.

JetBrains у документації описує TeamCity як CI/CD-сервер, який підтримує continuous integration і continuous delivery. Continuous Integration означає, що зміни коду регулярно потрапляють у спільний репозиторій, після чого автоматично запускається збірка для раннього виявлення проблем. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))

Зверніть увагу: TeamCity сам не пише код і не виправляє помилки. Він автоматизує перевірку, збірку, тестування, публікацію і розгортання, щоб команда швидше бачила, чи працюють зміни.

Для чого потрібен TeamCity

TeamCity потрібен для автоматизації процесів розробки та доставки програмного забезпечення.

Основні задачі TeamCity:

автоматичний запуск збірки після змін у репозиторії;
компіляція коду;
запуск unit-тестів;
запуск інтеграційних тестів;
запуск статичного аналізу;
перевірка якості коду;
створення артефактів;
публікація артефактів;
збірка Docker-образів;
запуск deployment;
контроль build history;
повідомлення про помилки;
контроль прав доступу;
робота з build chains;
автоматизація CI/CD-процесів.

Основні поняття TeamCity

TeamCity Server

TeamCity Server — це центральний сервер, який керує проєктами, build configurations, користувачами, правами доступу, історією збірок, артефактами, налаштуваннями, тригерами та результатами виконання.

Сервер координує роботу build agents, але сам зазвичай не виконує важкі build-задачі.

Build Agent

Build Agent — це окремий процес або машина, яка фактично виконує збірку. Саме build agent компілює код, запускає тести, виконує Gradle, Maven, npm, Docker, .NET CLI або інші команди.

У документації JetBrains зазначено, що build agent — це програмне забезпечення, яке виконує build process і встановлюється окремо від TeamCity Server. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))

Project

Project у TeamCity — це логічна група build configurations, налаштувань, шаблонів і параметрів. Один проєкт може відповідати одному програмному продукту, репозиторію, модулю або команді.

Build Configuration

Build Configuration — це опис конкретної збірки. У ньому задається, звідки брати код, які кроки виконувати, які тести запускати, які артефакти зберігати і коли запускати build.

Build Step

Build Step — це окремий крок у build configuration.

Приклади build steps:

Gradle build;
Maven build;
npm install;
npm test;
dotnet build;
dotnet test;
Docker build;
запуск shell-скрипта;
запуск PowerShell-скрипта;
публікація артефактів.

VCS Root

VCS Root — це налаштування підключення до репозиторію коду. Через VCS Root TeamCity знає, де знаходиться код, яку гілку брати, які облікові дані використовувати і які зміни відстежувати.

Практичне застосування: TeamCity дозволяє побудувати процес, у якому кожен commit автоматично перевіряється збіркою і тестами. Це допомагає швидше виявляти помилки та не переносити проблеми в production.

CI/CD у TeamCity

CI/CD означає Continuous Integration і Continuous Delivery або Continuous Deployment.

У TeamCity CI/CD може включати:

отримання коду з репозиторію;
автоматичний запуск build після commit;
компіляцію;
запуск тестів;
статичний аналіз;
створення артефактів;
публікацію Docker-образів;
deployment у тестове середовище;
ручне підтвердження перед production;
автоматичне розгортання за умовами.

JetBrains у власному CI/CD-гайді пояснює, що CI-сервер координує кроки CI/CD-процесу: від відстеження змін у VCS до запуску build, test і deployment-задач. ([jetbrains.com](https://www.jetbrains.com/teamcity/ci-cd-guide/ci-servers/))

Build chain

Build chain — це ланцюг взаємопов’язаних збірок. Він використовується, коли одна збірка залежить від результату іншої.

Приклад build chain:

Збірка backend.
Запуск backend-тестів.
Збірка frontend.
Запуск frontend-тестів.
Створення Docker-образу.
Deployment у staging.
Автоматичні smoke-тести.
Ручне підтвердження production deployment.

Build chain дозволяє бачити весь процес як єдиний pipeline і швидко визначати, на якому етапі сталася помилка.

Build triggers

Build Trigger визначає, коли запускати збірку.

Типові тригери:

запуск після commit у Git;
запуск за розкладом;
запуск після завершення іншої збірки;
ручний запуск користувачем;
запуск за тегом;
запуск для pull request або merge request;
запуск при зміні конкретної гілки;
запуск при зміні певних файлів.

Для команди розробки: найчастіше TeamCity налаштовують так, щоб build запускався автоматично після змін у репозиторії. Це дає швидкий зворотний зв’язок розробникам.

Build runners

Build Runner — це тип build step, який виконує конкретну технологічну задачу.

TeamCity може використовувати різні build runners:

Gradle;
Maven;
Ant;
.NET;
command line;
PowerShell;
Docker;
npm;
Python;
тестові runner-и;
deployment runner-и;
власні скрипти.

Для Java-проєкту, наприклад, build runner може запускати:

./gradlew clean build

Для .NET-проєкту:

dotnet test

Артефакти збірки

Build artifacts — це файли, які створюються після успішної збірки.

Приклади артефактів:

JAR-файл;
WAR-файл;
ZIP-архів;
Docker image;
NuGet-пакет;
npm package;
звіти тестів;
coverage report;
лог-файли;
інсталяційний пакет;
зібраний frontend.

TeamCity може зберігати артефакти, передавати їх у наступні build configurations або публікувати в зовнішній registry.

Configuration as Code

TeamCity підтримує підхід Configuration as Code. Це означає, що налаштування build configurations можна зберігати у вигляді коду в репозиторії.

JetBrains серед можливостей TeamCity окремо вказує configuration as code, customization and extensibility, metrics and insights, CI, test automation, security and compliance. ([jetbrains.com](https://www.jetbrains.com/teamcity/features/))

Переваги Configuration as Code:

налаштування зберігаються в Git;
зміни можна переглядати через code review;
простіше відновити конфігурацію;
простіше копіювати pipeline між проєктами;
можна відстежувати історію змін;
менше ручних змін через інтерфейс.

Kotlin DSL

TeamCity може використовувати Kotlin DSL для опису build configurations як коду. Це зручно для команд, які працюють з Kotlin або Java-екосистемою.

Приклад спрощеної ідеї Kotlin DSL:

project {
    buildType(Build)
}

object Build : BuildType({
    name = "Build"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        gradle {
            tasks = "clean build"
        }
    }
})

Інтеграційний акцент: для великих команд TeamCity краще налаштовувати через Kotlin DSL або шаблони. Це зменшує хаос у build configurations і дозволяє керувати CI/CD як частиною репозиторію.

TeamCity Cloud і TeamCity On-Premises

TeamCity може використовуватися у хмарному або локальному варіанті.

TeamCity Cloud

TeamCity Cloud — це керований хмарний варіант TeamCity, де частину інфраструктурних задач бере на себе JetBrains.

Такий варіант може бути зручним, якщо команда не хоче самостійно адмініструвати TeamCity Server.

TeamCity On-Premises

TeamCity On-Premises — це варіант, коли TeamCity Server встановлюється на сервері компанії або в її хмарній інфраструктурі.

Офіційна документація JetBrains описує TeamCity On-Premises як CI/CD-рішення для різних workflows і development practices. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/teamcity-documentation.html))

On-Premises може бути зручним, якщо потрібен більший контроль над інфраструктурою, мережами, агентами, секретами, доступом до внутрішніх репозиторіїв і deployment-середовищ.

Інтеграція з Git

TeamCity може інтегруватися з системами контролю версій.

Типові варіанти:

Git;
GitHub;
GitLab;
Bitbucket;
Azure DevOps Repos;
інші VCS залежно від налаштувань.

Інтеграція дозволяє:

відстежувати зміни;
запускати build після commit;
запускати build для pull request;
показувати автора змін;
відображати changelog;
прив’язувати build до конкретного commit;
повертати статус перевірки в репозиторій.

Інтеграція з Docker

TeamCity може використовуватися для Docker-сценаріїв:

збірка Docker image;
запуск контейнерів для тестів;
публікація image у registry;
deployment контейнерів;
запуск сервісів залежностей для тестів;
робота з Docker Compose;
підготовка середовища для integration tests.

Інтеграція з Gradle і Java

Для Java-проєктів TeamCity часто запускає Gradle або Maven.

Приклад Gradle-команди:

./gradlew clean test build

TeamCity може зберігати результати тестів, показувати failed tests, будувати історію стабільності тестів і повідомляти команду про проблеми.

Інтеграція з .NET

Для .NET-проєктів TeamCity може запускати:

dotnet restore;
dotnet build;
dotnet test;
dotnet publish;
NuGet pack;
deployment scripts.

Це корисно для C#, ASP.NET Core, API, backend-сервісів, desktop-застосунків і бібліотек.

Тестування в TeamCity

TeamCity може збирати і показувати результати тестів.

Типові тести:

unit-тести;
integration-тести;
API-тести;
UI-тести;
smoke-тести;
regression-тести;
performance-тести залежно від процесу.

TeamCity дозволяє бачити:

які тести впали;
у якому build вони впали;
хто зробив зміни перед падінням;
скільки часу виконувалися тести;
які тести нестабільні;
історію результатів.

Рекомендація: у CI/CD потрібно розділяти швидкі unit-тести та довші інтеграційні тести. Швидкі тести варто запускати на кожен commit, а важкі перевірки — окремо або за розкладом.

Deployment у TeamCity

TeamCity може брати участь у deployment-процесах. Це може бути автоматичне або ручне розгортання.

Типові deployment-сценарії:

deployment у staging;
deployment у testing;
deployment у production після ручного підтвердження;
публікація Docker image;
оновлення Kubernetes deployment;
завантаження артефакту на сервер;
запуск Ansible або shell-скрипта;
оновлення SaaS-сервісу;
rollback за потреби.

JetBrains у CI/CD-гайді пояснює різницю між continuous delivery і continuous deployment: у continuous delivery production-реліз запускається вручну, а в continuous deployment — автоматично після успішного проходження попередніх етапів. ([jetbrains.com](https://www.jetbrains.com/teamcity/ci-cd-guide/continuous-deployment/))

TeamCity у K2 ERP

У контексті K2 ERP TeamCity може використовуватися для автоматизації розробки, тестування і розгортання модулів ERP, інтеграційних сервісів, API, frontend, backend, Java, .NET, Python або інших компонентів.

TeamCity може бути корисним для:

збірки backend-сервісів;
збірки frontend;
запуску unit-тестів;
запуску інтеграційних тестів;
перевірки модулів ЕДО;
перевірки інтеграцій з ДПС;
перевірки інтеграцій з Medoc REST API;
перевірки інтеграцій з EDIN, СОТА, FREDO;
перевірки SAF-T UA XML;
збірки Docker-образів;
deployment у тестове середовище;
deployment у production після підтвердження;
зберігання артефактів релізів.

Для K2 ERP: TeamCity бажано використовувати як центральний CI/CD-сервер для модулів системи. Він має запускати тести, перевірки, збірку, створення артефактів і контрольований deployment у середовища.

Типовий сценарій CI для K2 ERP

Типовий CI-процес може виглядати так:

Розробник створює гілку в Git.
Розробник вносить зміни в модуль K2 ERP.
Код відправляється в репозиторій.
TeamCity отримує сигнал про зміни.
Запускається build configuration.
Build agent завантажує код.
Виконується збірка.
Запускаються тести.
Виконується статичний аналіз.
Формуються артефакти.
TeamCity показує результат.
Команда отримує повідомлення про успіх або помилку.

Типовий сценарій CD для K2 ERP

Типовий CD-процес може виглядати так:

TeamCity успішно завершує CI-збірку.
Створюється артефакт або Docker image.
Артефакт публікується в registry або сховище.
Запускається deployment у тестове середовище.
Виконуються smoke-тести.
Відповідальна особа підтверджує production deployment.
TeamCity запускає production deployment.
Система перевіряє стан сервісу після оновлення.
Результат deployment зберігається в історії.

Дані, які бажано зберігати

У TeamCity або пов’язаних системах бажано зберігати:

назву build configuration;
номер build;
commit hash;
автора змін;
гілку;
статус build;
дату і час запуску;
дату і час завершення;
build log;
результати тестів;
артефакти;
версію застосунку;
Docker image tag;
середовище deployment;
користувача, який запустив deployment;
причину помилки;
історію змін pipeline.

Можливі помилки під час роботи

Під час роботи з TeamCity можуть виникати такі проблеми:

build agent недоступний;
неправильні облікові дані до Git;
репозиторій недоступний;
неправильна гілка;
не встановлений потрібний SDK;
не встановлений Docker;
помилка Gradle або Maven;
помилка npm;
тести падають;
нестабільні тести;
не вистачає пам’яті на build agent;
неправильно налаштовані змінні середовища;
відсутній секрет або токен;
немає прав на deployment;
артефакт не збережено;
production deployment запущено помилково.

Рекомендація: усі deployment-збірки, особливо production, мають мати обмежені права доступу, журнал запусків, зрозумілі параметри, ручне підтвердження або чіткі автоматичні умови.

Безпека TeamCity

Для безпечної роботи TeamCity потрібно контролювати:

права користувачів;
групи доступу;
доступ до проєктів;
доступ до production deployment;
секрети;
токени;
SSH-ключі;
доступ до Docker registry;
доступ до build agents;
журнал дій;
оновлення TeamCity;
оновлення build agents;
ізоляцію агентів;
доступ до артефактів;
доступ до логів;
доступ до змінних середовища.

Дані, які не варто відкривати в build logs

У build logs не варто виводити:

паролі;
токени API;
приватні ключі;
production connection strings;
ключі електронного підпису;
секрети CI/CD;
персональні дані клієнтів;
конфіденційні фінансові дані;
вміст production-баз;
приватні сертифікати.

Не плутати: TeamCity може зберігати секрети як параметри збірки, але їх не можна виводити в логах або передавати в незахищені скрипти. CI/CD має бути налаштований так, щоб секрети не потрапляли в артефакти або повідомлення.

Переваги TeamCity

До основних переваг TeamCity можна віднести:

зручний вебінтерфейс;
підтримку CI/CD-процесів;
build agents;
build chains;
інтеграцію з Git;
підтримку Gradle, Maven, .NET, Docker та інших інструментів;
зберігання історії збірок;
показ результатів тестів;
підтримку Configuration as Code;
Kotlin DSL;
контроль прав доступу;
гнучкі тригери;
інтеграцію з JetBrains-екосистемою;
підтримку on-premises і cloud-сценаріїв.

Обмеження та ризики

Під час впровадження TeamCity потрібно враховувати:

потребу в адмініструванні сервера;
потребу в build agents;
потребу в ліцензіях залежно від масштабу;
потребу в налаштуванні доступів;
потребу в контролі секретів;
потребу в оновленнях;
потребу в резервному копіюванні;
ризик накопичення складних build configurations;
ризик нестабільних тестів;
ризик неконтрольованого deployment;
потребу в моніторингу диску, CPU і пам’яті.

Висновок

TeamCity — це CI/CD-сервер JetBrains для автоматизації збірки, тестування, публікації артефактів і розгортання програмного забезпечення.

Для команд, які розробляють ERP, SaaS, API, інтеграційні сервіси, Java, .NET, Docker або мікросервісні системи, TeamCity може бути центральним інструментом контролю якості та доставки змін. У K2 ERP TeamCity доцільно використовувати для автоматизованих збірок, тестів, перевірок інтеграцій, формування артефактів і контрольованого deployment у різні середовища.