R: Первинна публікація

2026-05-08T10:17:58Z

Первинна публікація

Нова сторінка

'''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))<div style="background:#e8f4ff; border-left:5px solid #1e88e5; padding:12px; margin:12px 0;">
'''Важливо:''' TeamCity — це не IDE і не система контролю версій. Це сервер автоматизації CI/CD, який отримує код із Git або іншої VCS, запускає збірку, тести, перевірки, створює артефакти та може виконувати deployment.
</div>

== Загальний опис ==
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))<div style="background:#fff8e1; border-left:5px solid #f9a825; padding:12px; margin:12px 0;">
'''Зверніть увагу:''' TeamCity сам не пише код і не виправляє помилки. Він автоматизує перевірку, збірку, тестування, публікацію і розгортання, щоб команда швидше бачила, чи працюють зміни.
</div>

== Для чого потрібен 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 знає, де знаходиться код, яку гілку брати, які облікові дані використовувати і які зміни відстежувати.<div style="background:#e8f5e9; border-left:5px solid #43a047; padding:12px; margin:12px 0;">
'''Практичне застосування:''' TeamCity дозволяє побудувати процес, у якому кожен commit автоматично перевіряється збіркою і тестами. Це допомагає швидше виявляти помилки та не переносити проблеми в production.
</div>

== 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;
* запуск при зміні конкретної гілки;
* запуск при зміні певних файлів.

<div style="background:#e0f2f1; border-left:5px solid #00897b; padding:12px; margin:12px 0;">
'''Для команди розробки:''' найчастіше TeamCity налаштовують так, щоб build запускався автоматично після змін у репозиторії. Це дає швидкий зворотний зв’язок розробникам.
</div>

== 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 може запускати:<syntaxhighlight lang="bash">
./gradlew clean build
</syntaxhighlight>Для .NET-проєкту:<syntaxhighlight lang="bash">
dotnet test
</syntaxhighlight>

== Артефакти збірки ==
'''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:<syntaxhighlight lang="kotlin">
project {
buildType(Build)
}

object Build : BuildType({
name = "Build"

vcs {
root(DslContext.settingsRoot)
}

steps {
gradle {
tasks = "clean build"
}
}
})
</syntaxhighlight><div style="background:#f3e5f5; border-left:5px solid #8e24aa; padding:12px; margin:12px 0;">
'''Інтеграційний акцент:''' для великих команд TeamCity краще налаштовувати через Kotlin DSL або шаблони. Це зменшує хаос у build configurations і дозволяє керувати CI/CD як частиною репозиторію.
</div>

== 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-команди:<syntaxhighlight lang="bash">
./gradlew clean test build
</syntaxhighlight>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 вони впали;
* хто зробив зміни перед падінням;
* скільки часу виконувалися тести;
* які тести нестабільні;
* історію результатів.

<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">
'''Рекомендація:''' у CI/CD потрібно розділяти швидкі unit-тести та довші інтеграційні тести. Швидкі тести варто запускати на кожен commit, а важкі перевірки — окремо або за розкладом.
</div>

== 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 після підтвердження;
* зберігання артефактів релізів.

<div style="background:#ede7f6; border-left:5px solid #5e35b1; padding:12px; margin:12px 0;">
'''Для K2 ERP:''' TeamCity бажано використовувати як центральний CI/CD-сервер для модулів системи. Він має запускати тести, перевірки, збірку, створення артефактів і контрольований deployment у середовища.
</div>

== Типовий сценарій 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 запущено помилково.

<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">
'''Рекомендація:''' усі deployment-збірки, особливо production, мають мати обмежені права доступу, журнал запусків, зрозумілі параметри, ручне підтвердження або чіткі автоматичні умови.
</div>

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

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

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

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

<div style="background:#ffebee; border-left:5px solid #e53935; padding:12px; margin:12px 0;">
'''Не плутати:''' TeamCity може зберігати секрети як параметри збірки, але їх не можна виводити в логах або передавати в незахищені скрипти. CI/CD має бути налаштований так, щоб секрети не потрапляли в артефакти або повідомлення.
</div>

== Переваги 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 у різні середовища.

== Джерела ==

* [https://www.jetbrains.com/teamcity/ TeamCity — JetBrains]
* [https://www.jetbrains.com/teamcity/features/ TeamCity Features]
* [https://www.jetbrains.com/help/teamcity/teamcity-documentation.html TeamCity Documentation]
* [https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html Continuous Integration with TeamCity]
* [https://www.jetbrains.com/teamcity/ci-cd-guide/ci-servers/ What is a CI server?]
* [https://www.jetbrains.com/teamcity/ci-cd-guide/continuous-deployment/ Continuous Deployment — TeamCity Guide]

== Див. також ==
[[Java]]

[[Gradle]]

[[Rider]]

[[SaaS]]

[[OpenCart]]

[[Tilda Commerce]]

[[Medoc REST API]]

[[M.E.Doc.ЕДО]]

[[Edin]]

[[FREDO]]

[[СОТА]]

[[ДПС]]

[[SAF-T UA]]

[[Е-ТТН]]

[[Інтеграція РРО в Python]]

[[Технічне завдання: Редактор ER-моделей K2 ERP]]

[[Технічне завдання: Редактор BP-моделей K2 ERP]]

TeamCity - Історія редагувань

R: Первинна публікація