Налаштування CI/CD конвеєра через TeamCity: Kotlin DSL і хмарні агенти

TeamCity налаштування: де ламається конвеєр збірки

Налаштування TeamCity починається не з екрана збірки, а з питання: скільки часу минає від коміту до робочого стенда. Якщо відповідь «година й більше», вузьке місце майже завжди на стиках — черга агентів, ручні кроки між збіркою та викаткою, неузгоджені середовища.

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

Ручні кроки в релізі — друга точка втрат. Поки артефакт переносять вручну або чекають на того, хто знає, що натиснути, доставка змін іде ривками: наприкінці тижня ніхто не ризикує, а до початку наступного накопичується пачка правок, яку складніше перевірити.

Невідтворюваність середовища дає найдорожчий клас відмов: локально все зелене, на агенті — ні. Різні версії інструментів, прогріті кеші та змінні середовища перетворюють розбір на перебір гіпотез.

Окремо — нестабільні перевірки. Тест, що падає через раз, привчає команду не дивитися на червоний статус, і справжня поломка йде в основну гілку разом із ним.

Тому ми дивимося на конвеєр як на систему: де він чекає, де залежить від людини і де результат не повторюється. Нижче розбираємо, як це закривається — від конфігурації, описаної кодом на Kotlin DSL, до хмарних агентів, які масштабуються під навантаження.

TeamCity налаштування: що змінюється у швидкості та надійності

Налаштування TeamCity починається не з установки сервера, а з інвентаризації того, що в проєкті досі робиться руками. Далі збірка описується кодом на Kotlin DSL, а важкі кроки переїжджають на хмарні агенти: вони піднімаються під навантаження і не простоюють між релізами.

Як скорочується час перевірок змін

Кешування залежностей і артефактів між запусками та розпаралелювання незалежних кроків скорочують час збірки в рази — перевірка змін на типовому сервісі зменшується з десятків хвилин до одиниць.

Розробник отримує результат за своєю гілкою, не чекаючи спільної черги на єдиному агенті, тому черга збірок перестає бути вузьким місцем у міру зростання команди.

Як зникає клас відмов від ручних операцій

Ручний крок ламає реліз однаково передбачувано: забули міграцію, зібрали з неправильної гілки, розгорнули не ту конфігурацію.

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

Підсумок вимірний: час збірки та швидкість перевірок змін скорочуються, простій команди через зламані збірки зникає, відкат на попередній артефакт стає звичайною операцією.

Хмарні та власні агенти збірки: вибір режиму роботи

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

Коли потрібен власний парк агентів

Свої машини виправдані, якщо збірці потрібен доступ у закритий контур, локальний реєстр або стенд без зовнішньої адреси. Друга ознака — стійкий потік: якщо в робочі години агенти зайняті постійно, парк дає передбачуваний час постановки в чергу.

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

Як рахується пікове навантаження на збірки

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

Далі зіставляємо з кількістю агентів і часом утримання — видно, скількох машин не вистачає в найгіршому вікні та скільки простоює зазвичай. Для гібридної схеми той самий розрахунок задає поріг, після якого завдання автоматично йдуть у хмарний пул.

Етапи робіт: від аудиту збірок до передачі регламентів

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

1. Аудит збірок — інвентаризація конфігурацій, вимірювання часу кожної збірки, пошук дубльованих перевірок і кроків, що залежать від стану конкретного агента.
2. Перенесення описів збірок у Kotlin DSL — конфігурації стають кодом: правка проходить перевірку перед злиттям, відкат робиться поверненням попередньої редакції файлу.
3. Схема середовищ — які гілки в що збираються, де лежать артефакти, які права в облікових записів і звідки беруться секрети.
4. Хмарні агенти — пули під типи завдань, автомасштабування проти черги в пік, ізоляція агентів один від одного.
5. Перевірка на копії продакшену — повний шлях збірки та викладки проганяємо на копії й звіряємо з поточним конвеєром.
6. Передача регламентів — як додати крок, відкотити випущену версію і що робити при падінні агента.

Схема середовищ і перенесення описів збірок

Схема відповідає на питання, що де запускається і куди потрапляє результат: репозиторії, пули агентів, артефакти, права. Поки вона не узгоджена, перенесення описів у код перетворюється на переписування тієї самої логіки під кожен проєкт.

Перевірка на копії продакшену

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

Що залишається у вас: конфігурації, схеми, регламенти

Впровадження закінчується не звітом, а набором робочих артефактів у вашому контурі. Конфігурації TeamCity, схеми середовищ і регламенти залишаються у вас у вигляді читабельних файлів і документів, а не закритого архіву — їх можна правити й передавати новому інженеру без нас.

Усе лежить у вашій системі контролю версій поруч із кодом: зміни проходять рев'ю й відкочуються як звичайний коміт.

• Конфігурація збірок — описи на Kotlin DSL у вашому репозиторії: кроки, тригери, залежності між збірками, параметри середовищ. Правки йдуть через гілку та рев'ю, а не через веб-інтерфейс.
• Документація зі збірок — що робить кожен крок, які артефакти він віддає, які перевірки обов'язкові перед викладкою.
• Схема середовищ — які середовища є, чим відрізняються, куди дивиться кожна гілка і як артефакт просувається до промислового контуру.
• Політики доступу — ролі та права: хто запускає збірку, хто затверджує викладку, які агенти до яких сховищ допущені. Плюс порядок видачі й відкликання доступів.
• Регламент супроводу — як додати крок, оновити агент, почистити кеш і відкотити реліз, із явною межею відповідальності між вами й нами.
• Інструкція з підключення хмарних агентів — як підняти нового агента, які в нього мітки та ліміти, як перевірити, що він потрапив у потрібний пул.

Така передача знімає головний ризик — залежність від людини, яка «знає, як тут усе влаштовано». Конфігурація версіонується, політики описані, регламент перевірено на живих релізах, а не написано з пам'яті.

Кейс: скоротили час збірки та прибрали ручні кроки

Проєкт — монорепозиторій на чотири команди: сервіси на Kotlin, спільна бібліотека, мобільна збірка. Конвеєр жив у TeamCity, але налаштовувався через веб-інтерфейс: кроки правили руками, конфігурації дублювалися між проєктами, зміни ніхто не рев'юив.

Що було до

Збірка займала 24–28 хвилин: половина кроків ішла послідовно, хоч не залежала один від одного. Реліз збирали вручну — 11 операцій від проставляння тегу до правки змінних середовища, кожна по 3–4 хвилини й з опорою на пам'ять відповідального.

Помилки були передбачувані: забутий тег, не той профіль збірки, неузгоджені конфігурації. Кожна третя збірка на основній гілці падала, а розбір займав більше 20 хвилин — у лозі змішувалися кроки всіх проєктів.

Як вимірювали результат і що вважали відмовою

Метрики знімали з історії збірок за 60 робочих днів до та після: медіана тривалості успішної збірки, частка падінь на основній гілці, кількість ручних операцій у чек-листі релізу, час від коміту до публікації артефакту.

Відмовою вважали будь-яке падіння не через код: недоступний агент, конфлікт версій залежностей, неправильний параметр середовища. Падіння з вини розробника вважали окремо — інакше метрика міряла б якість коду, а не конвеєра.

Опис збірки перевели в Kotlin DSL у репозиторії, агенти зробили хмарними й на одне завдання, кроки розпаралелили до шести та додали кеш залежностей. Медіана збірки — 8 хвилин, частка падінь — 4%, ручних операцій у релізі — одна, від коміту до артефакту — 14 хвилин.

Kotlin DSL чи збірка через веб-інтерфейс: що вибрати?

Коротка відповідь: якщо конвеєр змінюється частіше пари разів на квартал і над ним працюють кілька інженерів — описуйте збірку кодом на Kotlin DSL.

Якщо конфігурація стабільна і її править одна людина, веб-інтерфейсу TeamCity достатньо: репозиторій налаштувань додасть роботи без віддачі.

У Kotlin DSL опис збірки лежить у тому самому репозиторії, що й код. Будь-яка зміна — крок, залежність, параметр агента — приходить через запит на злиття: видно поручково, що і навіщо змінили та хто погодив, а відкат повертає попередній стан з історії.

Версіонування конфігурації та рев'ю змін збірки перестають бути домовленістю на словах — вони вбудовані в процес.

Веб-інтерфейс виграє у швидкості: налаштування кліками швидше для однотипних проєктів, історія правок зберігається всередині системи, і невеликій команді цього вистачає.

Обмеження проявляється на зростанні: спільні шаблони дублюються руками, а зрозуміти, чому збірка поводиться інакше, ніж пів року тому, можна лише за журналом усередині сервера.

Переходити можна поступово, без переписування всього одразу. Проєкт залишається у веб-інтерфейсі, а в код виноситься спільне: шаблони, параметри середовищ, правила запуску. Потім по одному переносяться конвеєри — з перевіркою, що поведінка збірки не змінилася.

Критерій простий: багато проєктів, гілок і обов'язкове погодження правок — Kotlin DSL; один-два стабільні конвеєри та один відповідальний — веб-інтерфейс. Змішаний режим теж робочий: він нарощує практику версіонування конфігурації там, де вона дає ефект.

Часті сумніви: доступи, секрети, відкат збірки

Сумніви, які найчастіше виникають до старту, майже завжди про одне: що буде, якщо щось зламається або витече. Нижче — п'ять питань, які ми розбираємо із замовником до першого коміту в TeamCity, і наші відповіді за замовчуванням.

Як розведені середовища, щоб тест не поїхав у прод?

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

Артефакт збирається один раз і просувається між середовищами, а не перезбирається заново: те, що пройшло перевірки, потрапляє в прод без змін. Так «працює на тесті, падає в проді» перестає бути класом відмов.

Що доступно агентам збірки і чи залишається щось після збірки?

Агент отримує лише ті параметри, які потрібні поточному кроку, і окремий ключ на читання репозиторію — без права писати. Хмарні агенти створюються під завдання й видаляються після нього, тому між проєктами та між запусками нічого не залишається.

Як оновлюються агенти і чи не стане конвеєр цілком?

Оновлення йде хвилею: спочатку оновлюється один агент і перевіряється на небойових збірках, потім решта. Сумісність версії агента й сервера перевіряємо до масового оновлення — інакше конвеєр стає цілком, і це саме та відмова, яка найдорожча за часом простою.

Що робити, якщо опис збірки пошкоджено або хтось його зламав?

Історія опису збірки зберігається в системі контролю версій, тому відкат — це revert коміту, а не ручна правка з пам'яті. Додатково тримаємо останній робочий артефакт і параметри його запуску: реліз можна перезібрати з того самого коміту, навіть якщо конвеєр зламано.

Обговоримо задачу: що потрібно для оцінки та плану робіт

Щоб повернутися з реалістичною оцінкою та планом, а не з вилкою «від і до», нам потрібен зліпок вашої поточної інфраструктури.

З налаштування TeamCity він дає розуміння обсягу робіт, етапів і ризиків — що можна винести в хмарні агенти, що доведеться залишити на своїх машинах і як пройти перехід без зупинки релізів.

• Інвентаризація збірок: скільки конфігурацій і проєктів у контурі, які мови та рантайми, де зберігаються артефакти, які збірки вже не використовуються і їх можна вивести.
• Поточний складальний конвеєр: чим запускається, які стадії проходить код від коміту до продакшену, де залишаються ручні кроки та ручні підтвердження.
• Вимоги до доступів: ролі в репозиторіях і реєстрі образів, де лежать секрети й хто їхній власник, чи потрібен окремий мережевий контур для складальних агентів.
• Середовище виконання: свої агенти чи хмарні, які ліцензії та квоти вже є, чи є обмеження за мережею, сховищем і тривалістю збірки.
• Критерії готовності: що вважаємо результатом — час збірки, частка перевірок, які проходять автоматично, і можливість відкату на попередній артефакт в один крок.
• Порядок передачі: хто приймає роботу, чи потрібні регламенти та інструкції для вашої команди, хто відповідає за конвеєр після запуску.

Опишіть задачу у вільній формі — за цими пунктами або як зручно. Ми повернемося з оцінкою, планом етапів і строками, а спірні місця щодо міграції та доступів розберемо окремо.