Перейти до вмісту

TeamCity

Матеріал з K2 ERP Wiki

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

  • у якому build вони впали;
  • хто зробив зміни перед падінням;
  • скільки часу виконувалися тести;
  • які тести нестабільні;
  • історію результатів.; # Збірка frontend.; # Виконуються smoke-тести.; # Команда отримує повідомлення про успіх або помилку.;

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

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

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

</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 користувачі можуть командам автоматизувати бізнес-процес розробки.;

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.ЕДО

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-проєкту:
    </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>
    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-сценаріїв.;

})

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

./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

У 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 має змогу запускати:

  1. TeamCity успішно завершує CI-збірку.;== Для чого потрібен TeamCity ==

TeamCity застосовується у Java.; TeamCity має змогу використовувати Kotlin DSL для опису build configurations як коду.; Build Trigger визначає, коли запускати збірку.; # Запуск frontend-тестів.;== Типовий сценарій CD для K2 ERP ==

</syntaxhighlight>

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
Отримано з https://wiki.corp2.eu/index.php?title=TeamCity&oldid=1158