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

TeamCity

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

Build Agent

Інтеграційний акцент: для великих команд TeamCity краще налаштовувати через Kotlin DSL або шаблони.SAF-T UA

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

Project

  • збірка Docker image;
  • запуск контейнерів для тестів;
  • публікація image у registry;
  • deployment контейнерів;
  • запуск сервісів залежностей для тестів;
  • робота з Docker Compose;
  • підготовка середовища для integration tests. Це оптимізує швидше виявляти помилки та не переносити проблеми в production. Project у TeamCity — це логічна група build configurations, налаштувань, шаблонів і параметрів. # TeamCity показує результат. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/teamcity-documentation.html))

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

TeamCity здатна інтегруватися з системами контролю версій.== інтеграційні функції ERP з Docker ==

Configuration as Code

  1. Збірка backend. # платформа перевіряє стан сервісу після оновлення версій. Такий варіант здатна бути зручним, якщо команда не хоче самостійно адмініструвати TeamCity Server. TeamCity здатна брати участь у deployment-процесах.== Джерела ==

інтеграційні функції ERP з Git

Build artifacts — це файли, які створюються після успішної збірки. TeamCity дає можливість бачити: OpenCart

Gradle ./gradlew clean test build TeamCity здатна зберігати артефакти, передавати їх у наступні build configurations або публікувати в зовнішній registry. інтеграційні функції ERP дає можливість: </syntaxhighlight> конкурентні переваги Configuration as Code:

} Приклади build steps:

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

project {

Приклад build chain:

</syntaxhighlight>Для .NET-проєкту:
== Build triggers ==

[[SaaS]]

* Git;
* GitHub;
* GitLab;
* Bitbucket;
* Azure DevOps Repos;
* інші VCS залежно від налаштувань. # Формуються артефакти. # Артефакт публікується в registry або сховище. TeamCity здатна використовуватися для Docker-сценаріїв:
<div style="background:#ede7f6; border-left:5px solid #5e35b1; padding:12px; margin:12px 0;">
== TeamCity Cloud і TeamCity On-Premises ==

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

* отримання коду з репозиторію;
* автоматичний запуск build після commit;
* компіляцію;
* запуск тестів;
* статичний аналіз;
* створення артефактів;
* публікацію Docker-образів;
* deployment у тестове середовище;
* ручне підтвердження перед production;
* автоматичне розгортання за умовами. * unit-тести;
* integration-тести;
* API-тести;
* UI-тести;
* smoke-тести;
* regression-тести;
* performance-тести залежно від процесу. # Build agent завантажує код.</div>
'''CI/CD''' означає '''Continuous Integration''' і '''Continuous Delivery''' або '''Continuous Deployment'''. Коли розробник надсилає зміни в репозиторій, TeamCity здатна автоматизовано запустити збірку, виконати тести, перевірити код, створити артефакт і повідомити команду про результат. # Виконується статичний аналіз. TeamCity підтримує підхід '''Configuration as Code'''.<div style="background:#e8f5e9; border-left:5px solid #43a047; padding:12px; margin:12px 0;">

== Deployment у TeamCity ==
</div>

'''TeamCity Cloud''' — це керований хмарний варіант TeamCity, де частину інфраструктурних задач бере на себе JetBrains. Це сервер автоматизації CI/CD, який отримує код із Git або іншої VCS, запускає збірку, тести, перевірки, створює артефакти та здатна виконувати deployment.=== TeamCity Cloud ===

* deployment у staging;
* deployment у testing;
* deployment у production після ручного підтвердження;
* публікація Docker image;
* оновлення версій Kubernetes deployment;
* завантаження артефакту на сервер;
* запуск Ansible або shell-скрипта;
* оновлення версій SaaS-сервісу;
* rollback за потреби. через TeamCity користувачі можуть командам цифровізувати бізнес-процес розробки. Це означає, що конфігурація build configurations можна зберігати у вигляді коду в репозиторії. # Запуск frontend-тестів.[[Технічне завдання: Редактор BP-моделей K2 ERP]]

* Gradle;
* Maven;
* Ant;
* .NET;
* command line;
* PowerShell;
* Docker;
* npm;
* Python;
* тестові runner-и;
* deployment runner-и;
* власні скрипти. '''Для команди розробки:''' найчастіше TeamCity налаштовують так, щоб build запускався автоматизовано після змін у репозиторії.=== TeamCity Server ===
'''критично:''' TeamCity — це не IDE і не платформа контролю версій. # Запуск backend-тестів. # Виконуються smoke-тести. JetBrains у CI/CD-гайді пояснює різницю між continuous delivery і continuous deployment: у continuous delivery production-реліз запускається вручну, а в continuous deployment — автоматизовано після успішного проходження попередніх етапів.</div>
Типові тести:

TeamCity потрібен для автоматизації процесів розробки та доставки програмного забезпечення. * build agent недоступний;
* неправильні облікові інформаційні дані до Git;
* репозиторій недоступний;
* неправильна гілка;
* не встановлений потрібний SDK;
* не встановлений Docker;
* помилка Gradle або Maven;
* помилка npm;
* тести падають;
* нестабільні тести;
* не вистачає пам’яті на build agent;
* неправильно налаштовані змінні середовища;
* відсутній секрет або токен;
* немає прав на deployment;
* артефакт не збережено;
* production deployment запущено помилково. Це інтуїтивно для команд, які працюють з Kotlin або Java-екосистемою.== інформаційні дані, які бажано зберігати ==
 }

* назву build configuration;
* номер build;
* commit hash;
* автора змін;
* гілку;
* статус build;
* дату і час запуску;
* дату і час завершення;
* build log;
* результати тестів;
* артефакти;
* версію застосунку;
* Docker image tag;
* середовище deployment;
* користувача, який запустив deployment;
* причину помилки;
* історію змін pipeline.== Тестування в TeamCity ==
'''Не плутати:''' TeamCity здатна зберігати секрети як параметри збірки, але їх не можна виводити в логах або передавати в незахищені скрипти. name = "Build"
'''Практичне сценарії використання:''' TeamCity дає можливість побудувати бізнес-процес, у якому кожен commit автоматизовано перевіряється збіркою і тестами. Continuous Integration означає, що зміни коду регулярно потрапляють у спільний репозиторій, після чого автоматизовано запускається збірка для раннього виявлення проблем. Він має запускати тести, перевірки, збірку, створення артефактів і контрольований deployment у середовища. # TeamCity запускає production deployment.=== Build Step ===

JetBrains серед можливостей TeamCity окремо вказує configuration as code, customization and extensibility, metrics and insights, CI, test automation, security and compliance.</div>

* відстежувати зміни;
* запускати build після commit;
* запускати build для pull request;
* показувати автора змін;
* відображати changelog;
* прив’язувати build до конкретного commit;
* повертати статус перевірки в репозиторій. # Запускається deployment у тестове середовище.== Артефакти збірки ==

<div style="background:#e0f2f1; border-left:5px solid #00897b; padding:12px; margin:12px 0;">
<div style="background:#fff3e0; border-left:5px solid #fb8c00; padding:12px; margin:12px 0;">

У типовому процесі TeamCity підключається до репозиторію коду, як приклад Git, GitHub, GitLab, Bitbucket або іншої системи контролю версій. Через VCS Root TeamCity знає, де знаходиться код, яку гілку брати, які облікові інформаційні дані використовувати і які зміни відстежувати.[[Tilda Commerce]]

[[Інтеграція РРО в Python]]
Build chain дає можливість бачити весь бізнес-процес як єдиний pipeline і оперативно визначати, на якому етапі сталася помилка. Це зменшує хаос у build configurations і дає можливість керувати CI/CD як частиною репозиторію. '''Build Configuration''' — це SEO-опис конкретної збірки. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))
'''Для K2 ERP:''' TeamCity бажано використовувати як центральний CI/CD-сервер для модулів системи. JetBrains описує TeamCity як CI/CD-сервер, а його build-система складається із сервера та build agents. # Розробник вносить зміни в компонент K2 ERP. '''Build Trigger''' визначає, коли запускати збірку. '''VCS Root''' — це конфігурація підключення до репозиторію коду. * запуск після commit у Git;
* запуск за розкладом;
* запуск після завершення іншої збірки;
* ручний запуск користувачем;
* запуск за тегом;
* запуск для pull request або merge request;
* запуск при зміні конкретної гілки;
* запуск при зміні певних файлів. }

dotnet test
== конкурентні переваги TeamCity ==

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

* Gradle build;
* Maven build;
* npm install;
* npm test;
* dotnet build;
* dotnet test;
* Docker build;
* запуск shell-скрипта;
* запуск PowerShell-скрипта;
* публікація артефактів. Для Java-проєктів TeamCity часто запускає Gradle або Maven. Це здатна бути автоматичне або ручне розгортання. * автоматичний запуск збірки після змін у репозиторії;
* компіляція коду;
* запуск unit-тестів;
* запуск інтеграційних тестів;
* запуск статичного аналізу;
* перевірка якості коду;
* створення артефактів;
* публікація артефактів;
* збірка Docker-образів;
* запуск deployment;
* контроль build history;
* повідомлення про помилки;
* контроль прав доступу;
* робота з build chains;
* автоматизація процесів CI/CD-процесів. # Виконується збірка. У K2 ERP TeamCity доцільно використовувати для автоматизованих збірок, тестів, перевірок інтеграцій, формування артефактів і контрольованого deployment у різні середовища. JetBrains у власному CI/CD-гайді пояснює, що CI-сервер координує кроки CI/CD-процесу: від відстеження змін у VCS до запуску build, test і deployment-задач. Приклади артефактів:

* паролі;
* токени API;
* приватні ключі;
* production connection strings;
* ключі електронного підпису;
* секрети CI/CD;
* персональні інформаційні дані клієнтів;
* конфіденційні фінансові інформаційні дані;
* вміст production-баз;
* приватні сертифікати. # Код відправляється в репозиторій. Саме build agent компілює код, запускає тести, виконує Gradle, Maven, npm, Docker, .NET CLI або інші команди.== TeamCity у K2 ERP ==
TeamCity здатна зберігати результати тестів, показувати failed tests, будувати історію стабільності тестів і повідомляти команду про проблеми. # Результат deployment зберігається в історії. У TeamCity або пов’язаних системах бажано зберігати:

ДПС

VCS Root

інтеграційні функції ERP з Gradle і Java

CI/CD у TeamCity

object Build : BuildType({

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

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

Безпека TeamCity

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

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

TeamCity здатна використовуватися у хмарному або локальному варіанті. # Запускаються тести.== Можливі помилки під час роботи ==

Build Agent — це окремий бізнес-процес або машина, яка фактично виконує збірку. У ньому задається, звідки брати код, які кроки виконувати, які тести запускати, які артефакти зберігати і коли запускати build. root(DslContext.settingsRoot)

  • які тести впали;
  • у якому build вони впали;
  • хто зробив зміни перед падінням;
  • скільки часу виконувалися тести;
  • які тести нестабільні;
  • історію результатів.== інформаційні дані, які не варто відкривати в build logs ==

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

  1. TeamCity успішно завершує CI-збірку. ([jetbrains.com](https://www.jetbrains.com/help/teamcity/continuous-integration-with-teamcity.html))

TeamCity On-Premises

gradle {

Build chain

інтеграційні функції ERP з .NET

  • dotnet restore;
  • dotnet build;
  • dotnet test;
  • dotnet publish;
  • NuGet pack;
  • deployment scripts. У TeamCity CI/CD здатна включати:

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

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

Приклад Gradle-команди:<syntaxhighlight lang="bash">
Під час роботи з TeamCity можуть виникати такі проблеми:
Типовий CD-процес здатна виглядати так:
== Див. так само ==
[[СОТА]]
[[M.E.Doc.ЕДО]]
'''Рекомендація:''' у CI/CD потрібно розділяти швидкі unit-тести та довші інтеграційні тести.== Kotlin DSL ==

* збірки backend-сервісів;
* збірки frontend;
* запуску unit-тестів;
* запуску інтеграційних тестів;
* перевірки модулів ЕДО;
* перевірки інтеграцій з ДПС;
* перевірки інтеграцій з Medoc REST API;
* перевірки інтеграцій з EDIN, СОТА, FREDO;
* перевірки SAF-T UA XML;
* збірки Docker-образів;
* deployment у тестове середовище;
* deployment у production після підтвердження;
* зберігання артефактів релізів. * JAR-файл;
* WAR-файл;
* ZIP-архів;
* Docker image;
* NuGet-пакет;
* npm package;
* звіти тестів;
* coverage report;
* лог-файли;
* інсталяційний пакет;
* зібраний frontend. # Запускається build configuration. # Створення Docker-образу. # Збірка frontend. ([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 сам не пише код і не виправляє помилки. ([jetbrains.com](https://www.jetbrains.com/teamcity/features/))
Типові deployment-сценарії:

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

[[Е-ТТН]]

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

TeamCity здатна збирати і показувати результати тестів. # Автоматичні smoke-тести. Він застосовується для, коли одна збірка залежить від результату іншої. # Команда отримує повідомлення про успіх або помилку.[[Rider]]
On-Premises здатна бути зручним, якщо потрібен більший контроль над інфраструктурою, мережами, агентами, секретами, доступом до внутрішніх репозиторіїв і deployment-середовищ. '''TeamCity Server''' — це центральний сервер, який керує проєктами, build configurations, користувачами, правами доступу, історією збірок, артефактами, налаштуваннями, тригерами та результатами виконання.[[FREDO]]

# Розробник створює гілку в Git. У документації JetBrains зазначено, що build agent — це програмне забезпечення (ПЗ), яке виконує build process і встановлюється окремо від TeamCity Server. TeamCity застосовується у Java. JetBrains у документації описує TeamCity як CI/CD-сервер, який підтримує continuous integration і continuous delivery.== Build runners ==
TeamCity здатна бути корисним для:
</div>

</div>
TeamCity здатна використовувати '''Kotlin DSL''' для опису build configurations як коду. Для команд, які розробляють ERP, SaaS, API, інтеграційні сервіси, Java, .NET, Docker або мікросервісні системи, TeamCity здатна бути центральним інструментом контролю якості та доставки змін.</div>

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

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

'''Build chain''' — це ланцюг взаємопов’язаних збірок.[[Edin]]

 }

Це корисно для C#, ASP.NET Core, API, backend-сервісів, desktop-застосунків і бібліотек.== Типовий сценарій CD для K2 ERP == Java

}) TeamCity здатна використовувати різні build runners:

./gradlew clean build Рекомендація: усі deployment-збірки, особливо production, мають мати обмежені права доступу, журнал запусків, зрозумілі параметри, ручне підтвердження або чіткі автоматичні умови. # Ручне підтвердження production deployment. Окремо варто відзначити .NET, Kotlin, JavaScript, Python, Android, Docker, мікросервісних, backend, frontend, mobile, SaaS і корпоративних проєктах.== Висновок ==

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

TeamCity — це CI/CD-сервер JetBrains для автоматизації збірки, тестування, публікації артефактів і розгортання програмного забезпечення. TeamCity On-Premises — це варіант, коли TeamCity Server встановлюється на сервері компанії або в її хмарній інфраструктурі. Один проєкт здатна відповідати одному програмному продукту, репозиторію, модулю або команді. # TeamCity отримує сигнал про зміни. Швидкі тести варто запускати на кожен commit, а важкі перевірки — окремо або за розкладом. ([jetbrains.com](https://www.jetbrains.com/teamcity/ci-cd-guide/ci-servers/))

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

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

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

Офіційна документація JetBrains описує TeamCity On-Premises як CI/CD-рішення для різних workflows і development practices. Це дає швидкий зворотний зв’язок розробникам. # Відповідальна особа підтверджує production deployment. ([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-сценаріїв. # Створюється артефакт або Docker image. Після появи нових змін CI/CD-сервер запускає потрібні build configurations на build agents. buildType(Build)

Для Java-проєкту, як приклад, build runner здатна запускати:<syntaxhighlight lang="bash">

Build Configuration

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

Отримано з https://wiki.kyiv.ua/index.php?title=TeamCity&oldid=1158