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

2026-05-08T10:17:58Z

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

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

автоматизації збірки забезпечується через '''TeamCity''' — це CI/CD-сервер від компанії '''JetBrains''', який застосовується; додатково реалізовано тестування, перевірки якості коду, публікації артефактів і розгортання програмного забезпечення.; * які тести впали;
* у якому build вони впали;
* хто зробив зміни перед падінням;
* скільки часу виконувалися тести;
* які тести нестабільні;
* історію результатів.; # Збірка frontend.; # Виконуються smoke-тести.; # Команда отримує повідомлення про успіх або помилку.;<div style="background:#e8f5e9; border-left:5px solid #43a047; padding:12px; margin:12px 0;">
До основних переваг TeamCity можна віднести:

'''Build chain''' — це ланцюг взаємопов’язаних збірок.; # платформа перевіряє стан сервісу після актуалізація.; Це сприяє швидше виявляти помилки та не переносити проблеми в production.; dotnet test

TeamCity потрібен для автоматизації процесів розробки та доставки програмного забезпечення.; Приклад спрощеної ідеї Kotlin DSL:<syntaxhighlight lang="kotlin">

</div>

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

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

TeamCity має змогу інтегруватися з системами контролю версій.; # TeamCity отримує сигнал про зміни.; У K2 ERP TeamCity доцільно використовувати для автоматизованих збірок, тестів, перевірок інтеграцій, формування артефактів і контрольованого deployment у різні середовища.; Для Java-проєктів TeamCity часто запускає Gradle або Maven.; Саме build agent компілює код, запускає тести, виконує Gradle, Maven, npm, Docker, .NET CLI або інші команди.;== інтеграційні функціональні можливості з .NET ==
== Артефакти збірки ==

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

'''Рекомендація:''' у CI/CD потрібно розділяти швидкі unit-тести та довші інтеграційні тести.; # Виконується збірка.; CI/CD має бути налаштований так, щоб секрети не потрапляли в артефакти або повідомлення.; # Код відправляється в репозиторій.; Офіційна документація JetBrains описує TeamCity On-Premises як CI/CD-рішення для різних workflows і development practices.; # Створення Docker-образу.; ([jetbrains.com](https://www.jetbrains.com/teamcity/features/))

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

* Git;
* GitHub;
* GitLab;
* Bitbucket;
* Azure DevOps Repos;
* інші VCS залежно від налаштувань.; JetBrains у документації описує TeamCity як CI/CD-сервер, який підтримує роботу continuous integration і continuous delivery.; TeamCity підтримує роботу підхід '''Configuration as Code'''.; ([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 має змогу зберігати артефакти, передавати їх у наступні build configurations або публікувати в зовнішній registry.; Типові тести:

'''Практичне сфера застосування:''' TeamCity надає можливість побудувати бізнес-процес, у якому кожен commit автономно перевіряється збіркою і тестами.; # Результат deployment зберігається в історії.; '''VCS Root''' — це конфігурація підключення до репозиторію коду.;</div>

[[FREDO]]
Приклади build steps:

tasks = "clean build"

* Gradle build;
* Maven build;
* npm install;
* npm test;
* dotnet build;
* dotnet test;
* Docker build;
* запуск shell-скрипта;
* запуск PowerShell-скрипта;
* публікація артефактів.;<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">
'''Project''' у TeamCity — це логічна група build configurations, налаштувань, шаблонів і параметрів.; Для Java-проєкту, як ілюстрація, build runner має змогу запускати:<syntaxhighlight lang="bash">
Для безпечної роботи TeamCity потрібно контролювати:

object Build : BuildType({

== інтеграційні функціональні можливості з Git ==

* [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]

root(DslContext.settingsRoot)
project {

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

== Джерела ==

У типовому процесі TeamCity підключається до репозиторію коду, як ілюстрація Git, GitHub, GitLab, Bitbucket або іншої системи контролю версій.; Типовий CI-процес має змогу виглядати так:
завдяки наявності TeamCity користувачі можуть командам автоматизувати бізнес-процес розробки.;</syntaxhighlight>
TeamCity має змогу бути корисним для:

* назву build configuration;
* номер build;
* commit hash;
* автора змін;
* гілку;
* статус build;
* дату і час запуску;
* дату і час завершення;
* build log;
* результати тестів;
* артефакти;
* версію застосунку;
* Docker image tag;
* середовище deployment;
* користувача, який запустив deployment;
* причину помилки;
* історію змін pipeline.; Це сервер автоматизації CI/CD, який отримує код із Git або іншої VCS, запускає збірку, тести, перевірки, створює артефакти та має змогу виконувати deployment.; Він автоматизує перевірку, збірку, тестування, публікацію і розгортання, щоб команда швидше бачила, чи працюють зміни.;=== TeamCity On-Premises ===
[[M.E.Doc.ЕДО]]

</div>
=== Build Step ===
Для команд, які розробляють ERP, SaaS, API, інтеграційні сервіси, Java, .NET, Docker або мікросервісні системи, TeamCity має змогу бути центральним інструментом контролю якості та доставки змін.; # Запуск backend-тестів.; # Запускається deployment у тестове середовище.; }
== CI/CD у TeamCity ==

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

=== Build Agent ===
=== TeamCity Cloud ===

TeamCity має змогу використовуватися у хмарному або локальному варіанті.; Він застосовується, коли одна збірка залежить від результату іншої.; # Виконується статичний аналіз.; ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))

== TeamCity Cloud і TeamCity On-Premises ==
}

інтеграційні функціональні можливості надає можливість:

== Build triggers ==

* конфігурація зберігаються в Git;
* зміни можна переглядати через code review;
* простіше відновити конфігурацію;
* простіше копіювати pipeline між проєктами;
* можна відстежувати історію змін;
* менше ручних змін через інтерфейс.; # Запускаються тести.; Це означає, що конфігурація build configurations можна зберігати у вигляді коду в репозиторії.; # Формуються артефакти.; # Build agent завантажує код.; Такий варіант має змогу бути зручним, якщо команда не хоче самостійно адмініструвати TeamCity Server.; Це комфортно для команд, які працюють з Kotlin або Java-екосистемою.;== інтеграційні функціональні можливості з Gradle і Java ==

* запуск після commit у Git;
* запуск за розкладом;
* запуск після завершення іншої збірки;
* ручний запуск користувачем;
* запуск за тегом;
* запуск для pull request або merge request;
* запуск при зміні конкретної гілки;
* запуск при зміні певних файлів.;</syntaxhighlight>Для .NET-проєкту:<syntaxhighlight lang="bash">
</div>

* паролі;
* токени API;
* приватні ключі;
* production connection strings;
* ключі електронного підпису;
* секрети CI/CD;
* персональні інформаційні дані клієнтів;
* конфіденційні фінансові інформаційні дані;
* вміст production-баз;
* приватні сертифікати.; Це зменшує хаос у build configurations і надає можливість керувати CI/CD як частиною репозиторію.; Коли розробник надсилає зміни в репозиторій, TeamCity має змогу автономно запустити збірку, виконати тести, перевірити код, створити артефакт і повідомити команду про результат.;== Див.; додатково ==
[[Rider]]
<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">
TeamCity має змогу використовуватися для Docker-сценаріїв:
[[Java]]

'''Build Step''' — це окремий крок у build configuration.; Типовий CD-процес має змогу виглядати так:
[[Інтеграція РРО в Python]]
== інформаційні дані, які бажано зберігати ==

'''істотно:''' TeamCity — це не IDE і не платформа контролю версій.;== інтеграційні функціональні можливості з Docker ==
Приклад build chain:
}

У TeamCity CI/CD має змогу включати:
[[ДПС]]

== інформаційні дані, які не варто відкривати в build logs ==

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

TeamCity має змогу брати участь у deployment-процесах.; steps {
== Build runners ==
== Kotlin DSL ==

== Обмеження та ризики ==
./gradlew clean build

* права користувачів;
* групи доступу;
* доступ до проєктів;
* доступ до production deployment;
* секрети;
* токени;
* SSH-ключі;
* доступ до Docker registry;
* доступ до build agents;
* журнал дій;
* актуалізація TeamCity;
* актуалізація build agents;
* ізоляцію агентів;
* доступ до артефактів;
* доступ до логів;
* доступ до змінних середовища.; # Deployment у staging.; JetBrains у власному CI/CD-гайді пояснює, що CI-сервер координує кроки CI/CD-процесу: від відстеження змін у VCS до запуску build, test і deployment-задач.; Це корисно для C#, ASP.NET Core, API, backend-сервісів, desktop-застосунків і бібліотек.; Окремо варто відзначити .NET, Kotlin, JavaScript, Python, Android, Docker, мікросервісних, backend, frontend, mobile, SaaS і корпоративних проєктах.; # Артефакт публікується в registry або сховище.; ([jetbrains.com](https://www.jetbrains.com/teamcity/ci-cd-guide/ci-servers/))
== Безпека TeamCity ==

* build agent недоступний;
* неправильні облікові інформаційні дані до Git;
* репозиторій недоступний;
* неправильна гілка;
* не встановлений потрібний SDK;
* не встановлений Docker;
* помилка Gradle або Maven;
* помилка npm;
* тести падають;
* нестабільні тести;
* не вистачає пам’яті на build agent;
* неправильно налаштовані змінні середовища;
* відсутній секрет або токен;
* немає прав на deployment;
* артефакт не збережено;
* production deployment запущено помилково.; ([jetbrains.com](https://www.jetbrains.com/help/teamcity/teamcity-documentation.html))

# Розробник створює гілку в Git.; Це дає швидкий зворотний зв’язок розробникам.; '''Рекомендація:''' усі deployment-збірки, особливо production, мають мати обмежені права доступу, журнал запусків, зрозумілі параметри, ручне підтвердження або чіткі автоматичні умови.; Приклад Gradle-команди:<syntaxhighlight lang="bash">

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

On-Premises має змогу бути зручним, якщо потрібен більший контроль над інфраструктурою, мережами, агентами, секретами, доступом до внутрішніх репозиторіїв і deployment-середовищ.; '''Build Configuration''' — це характеристика конкретної збірки.; # Створюється артефакт або Docker image.; Після появи нових змін CI/CD-сервер запускає потрібні build configurations на build agents.; Через VCS Root TeamCity знає, де знаходиться код, яку гілку брати, які облікові інформаційні дані використовувати і які зміни відстежувати.;<div style="background:#e0f2f1; border-left:5px solid #00897b; padding:12px; margin:12px 0;">

'''TeamCity Cloud''' — це керований хмарний варіант TeamCity, де частину інфраструктурних задач бере на себе JetBrains.; gradle {
'''Не плутати:''' TeamCity має змогу зберігати секрети як параметри збірки, але їх не можна виводити в логах або передавати в незахищені скрипти.; # Відповідальна особа підтверджує production deployment.; '''Build Runner''' — це тип build step, який виконує конкретну технологічну задачу.; TeamCity — це CI/CD-сервер JetBrains для автоматизації збірки, тестування, публікації артефактів і розгортання програмного забезпечення.; Швидкі тести варто запускати на кожен commit, а важкі перевірки — окремо або за розкладом.; # Збірка backend.;=== Build Configuration ===
TeamCity має змогу використовувати різні build runners:

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

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

* автоматичний запуск збірки після змін у репозиторії;
* компіляція коду;
* запуск unit-тестів;
* запуск інтеграційних тестів;
* запуск статичного аналізу;
* перевірка якості коду;
* створення артефактів;
* публікація артефактів;
* збірка Docker-образів;
* запуск deployment;
* контроль build history;
* повідомлення про помилки;
* контроль прав доступу;
* робота з build chains;
* автоматизація процесів CI/CD-процесів.; TeamCity має змогу збирати і показувати результати тестів.; Він має запускати тести, перевірки, збірку, створення артефактів і контрольований deployment у середовища.; Один проєкт має змогу відповідати одному програмному продукту, репозиторію, модулю або команді.; # Автоматичні smoke-тести.; У документації JetBrains зазначено, що build agent — це програмне забезпечення, яке виконує build process і встановлюється окремо від TeamCity Server.; Типові deployment-сценарії:

Build chain надає можливість бачити весь бізнес-процес як єдиний pipeline і оперативно визначати, на якому етапі сталася помилка.; '''TeamCity Server''' — це центральний сервер, який керує проєктами, build configurations, користувачами, правами доступу, історією збірок, артефактами, налаштуваннями, тригерами та результатами виконання.; # TeamCity показує результат.;== Висновок ==

[[Tilda Commerce]]
У контексті K2 ERP TeamCity має змогу використовуватися для автоматизації розробки, тестування і розгортання модулів ERP, інтеграційних сервісів, API, frontend, backend, Java, .NET, Python або інших компонентів.; У ньому задається, звідки брати код, які кроки виконувати, які тести запускати, які артефакти зберігати і коли запускати build.; ([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;">
</div>

== Тестування в TeamCity ==
</div>

* dotnet restore;
* dotnet build;
* dotnet test;
* dotnet publish;
* NuGet pack;
* deployment scripts.; Це має змогу бути автоматичне або ручне розгортання.;[[Gradle]]

== Deployment у TeamCity ==
TeamCity надає можливість бачити:

</div>
</syntaxhighlight>TeamCity має змогу зберігати результати тестів, показувати failed tests, будувати історію стабільності тестів і повідомляти команду про проблеми.; ([jetbrains.com](https://www.jetbrains.com/teamcity/ci-cd-guide/continuous-deployment/))

* зручний вебінтерфейс;
* підтримку CI/CD-процесів;
* build agents;
* build chains;
* інтеграцію з Git;
* підтримку Gradle, Maven, .NET, Docker та інших інструментів;
* зберігання історії збірок;
* показ результатів тестів;
* підтримку Configuration as Code;
* Kotlin DSL;
* контроль прав доступу;
* гнучкі тригери;
* інтеграцію з JetBrains-екосистемою;
* підтримку on-premises і cloud-сценаріїв.;<div style="background:#ffebee; border-left:5px solid #e53935; padding:12px; margin:12px 0;">
})

== Можливі помилки під час роботи ==
./gradlew clean test build

== переважні аспекти TeamCity ==
Сервер координує роботу build agents, але сам зазвичай не виконує важкі build-задачі.; JetBrains у CI/CD-гайді пояснює різницю між continuous delivery і continuous deployment: у continuous delivery production-реліз запускається вручну, а в continuous deployment — автономно після успішного проходження попередніх етапів.;== TeamCity у K2 ERP ==

* відстежувати зміни;
* запускати build після commit;
* запускати build для pull request;
* показувати автора змін;
* відображати changelog;
* прив’язувати build до конкретного commit;
* повертати статус перевірки в репозиторій.; '''Зверніть увагу:''' TeamCity сам не пише код і не виправляє помилки.; JetBrains описує TeamCity як CI/CD-сервер, а його build-система складається із сервера та build agents.; # Запускається build configuration.; '''Build Agent''' — це окремий бізнес-процес або машина, яка фактично виконує збірку.; '''CI/CD''' означає '''Continuous Integration''' і '''Continuous Delivery''' або '''Continuous Deployment'''.;[[Технічне завдання: Редактор ER-моделей K2 ERP]]

</div>

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

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

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

'''TeamCity On-Premises''' — це варіант, коли TeamCity Server встановлюється на сервері компанії або в її хмарній інфраструктурі.; '''Інтеграційний акцент:''' для великих команд TeamCity краще налаштовувати через Kotlin DSL або шаблони.; * Gradle;
* Maven;
* Ant;
* .NET;
* command line;
* PowerShell;
* Docker;
* npm;
* Python;
* тестові runner-и;
* deployment runner-и;
* власні скрипти.; '''Для K2 ERP:''' TeamCity бажано використовувати як центральний CI/CD-сервер для модулів системи.;[[SAF-T UA]]
Для .NET-проєктів TeamCity має змогу запускати:

# TeamCity успішно завершує CI-збірку.;== Для чого потрібен TeamCity ==
</div>
TeamCity застосовується у Java.; TeamCity має змогу використовувати '''Kotlin DSL''' для опису build configurations як коду.; '''Build Trigger''' визначає, коли запускати збірку.; # Запуск frontend-тестів.;== Типовий сценарій CD для K2 ERP ==
</syntaxhighlight><div style="background:#f3e5f5; border-left:5px solid #8e24aa; padding:12px; margin:12px 0;">

<div style="background:#ede7f6; border-left:5px solid #5e35b1; padding:12px; margin:12px 0;">
=== VCS Root ===

переважні аспекти Configuration as Code:

'''Для команди розробки:''' найчастіше TeamCity налаштовують так, щоб build запускався автономно після змін у репозиторії.;[[Е-ТТН]]

name = "Build"

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

}

* unit-тести;
* integration-тести;
* API-тести;
* UI-тести;
* smoke-тести;
* regression-тести;
* performance-тести залежно від процесу.; Під час роботи з TeamCity можуть виникати такі проблеми:

== Загальний характеристика ==

[[СОТА]]

У build logs не варто виводити:
JetBrains серед можливостей TeamCity окремо вказує configuration as code, customization and extensibility, metrics and insights, CI, test automation, security and compliance.; # Ручне підтвердження production deployment.; # Розробник вносить зміни в компонент K2 ERP.; vcs {

== Configuration as Code ==

[[SaaS]]

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

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