Збірки на Drone CI: що ламається при зростанні проєктів
Поки проєктів п’ять, контур збірки тримається на одній людині: вона пам’ятає порядок кроків, знає, які секрети підставити, і редагує конфігурацію вручну. На тридцяти проєктах і двох десятках інженерів той самий контур починає гальмувати не через код, а через організацію робіт.
Першим проступає вузьке місце збірки: спільний пул виконавців ділиться між усіма гілками, і черга завдань збірки зростає швидше, ніж команда. Збірка застосунку, яка вчора займала хвилини, чекає на звільнення виконавця, а розробник замість роботи дивиться на статус.
Друге джерело збоїв — розбіжність середовищ і приховані залежності. Бібліотеки, закешовані артефакти та змінні, які хтось задав в інтерфейсі й не переніс у конфігурацію: локально все зелене, на чистому виконавці — падіння.
Такі залежності не видно в репозиторії, доки не зміниться середовище або не відкличуть доступ до чужого акаунта.
Нарешті, ручний деплой: викладка тримається на людині, яка «вміє правильно», і у відпустці вона перетворюється на єдину точку відмови.
Drone CI прибирає цю залежність — контур збірки описується як код: кроки, середовища, правила викладки й допуски живуть у репозиторії поруч із застосунком. Розбираємо, як це закривається.
Автоматизація збірок і деплою: вимірюваний ефект
Перше, що змінюється, — час від коміту до перевіреного артефакту.
Стадії розбиваються за залежностями, кеш шарів і залежностей переживає між запусками, тому типове змінення збирається за хвилини, а не десятки хвилин, і розробник отримує зворотний зв’язок ще до перемикання контексту.
Частка паралельних кроків — другий вимірюваний параметр. Лінтери, модульні та інтеграційні тести, перевірки образу йдуть незалежними гілками, і критичний шлях скорочується до найдовшої з них: сумарний машинний час навіть зростає, а календарний падає.
Частота релізів піднімається як наслідок. Коли викладка однією кнопкою і відкат — теж одна операція, команда випускає дрібними порціями по кілька разів на день замість одного ризикованого релізу на тиждень.
Дрібна порція швидше перевіряється й дешевше відкочується, аварій стає менше просто тому, що реліз перестає бути подією.
Окремо про усунений клас відмов. Зникають розбіжності середовищ і ручні правки на серверах: Drone CI проганяє той самий набір кроків для тестового й робочого середовища, а стан кластера описано декларативно.
Клас «на тесті працювало, на проді ні» закривається на етапі збірки, а не на розборі після збою, і час відновлення вимірюється хвилинами — відкат це повторний запуск зафіксованої версії, а не ручна археологія.
Режими запуску збірок: хмара, власні агенти, гібрид
Режим запуску визначає, де фізично виконуються кроки збірки, до яких мереж і секретів має доступ завдання і хто відповідає за вузол.
У Drone CI кожне завдання йде в окремому контейнері, тому ізоляція збірок забезпечується на рівні кроку — але сам агент, який ці контейнери піднімає, обирає команда.
Питань під час вибору зазвичай два: чи потрібен доступ до приватних ресурсів — внутрішнього реєстру образів, сховища секретів, сервісів у закритому контурі — і наскільки строго потрібно розвести завдання різних команд.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарні агенти провайдера | Потрібен швидкий старт, немає власного майданчика, збірки публічного коду | Прямого доступу до закритого контуру немає, ресурси діляться з іншими орендарями |
| Власні постійні агенти | Є внутрішні залежності та власні вимоги до контролю доступу | Вузли живуть між запусками: залишки файлів, кеш і стан робочої папки потрібно чистити |
| Ефемерні агенти в кластері | Потрібне чисте середовище на кожну збірку й керування навантаженням | Потребують кластера, налаштування прав і лімітів; холодний старт довший |
| Гібридна схема | Збірки за гілками йдуть у хмару, релізні — у внутрішній контур | Два пули треба обслуговувати й синхронізувати |
Гібрид на практиці беруть найчастіше: рядові збірки не займають внутрішні вузли, а реліз і робота з секретами залишаються в контрольованому контурі. Умова одна — однакові образи, версії плагінів і правила кешу в обох пулах, інакше результат перестає відтворюватися. Режим задається в конфігурації агента, тому змінити схему можна без переписування збіркових файлів.
Впровадження Drone CI: етапи інженерної роботи
Перемикання йде без зупинки релізів: поки новий контур перевіряється, старий продовжує збирати гілки. Нижче — послідовність етапів, яку проходимо під час впровадження Drone CI у Kubernetes.
-
Аудит процесів збірки. Дивимося, що досі збирається вручну, на яких кроках збірки падають найчастіше, скільки займає шлях від коміту до середовища і де розкидані ключі доступу. На виході — карта поточного стану й список збірок, які переводимо першими.
-
Схема контуру. Визначаємо, де розміщуються сервер керування й агенти, як вони отримують доступ до кластера, які гілки відповідають яким середовищам і хто бачить секрети. Схему фіксуємо до налаштування — вона задає всі інші рішення.
-
Налаштування агентів і політик. Розводимо агенти за типами завдань, вмикаємо кеш шарів збірки й ліміти за ресурсами, прописуємо правила запуску: що збирається на кожен коміт, що — на тег, що чекає ручного підтвердження перед бойовим контуром.
-
Перенесення збірок. Репозиторії переводимо поступово, по одному сервісу, з паралельною роботою старого контуру. Команда бачить результат на першій же збірці, а не після повного перемикання.
-
Перевірка на реальному релізі. Проганяємо звичайний реліз, а не демонстраційний: від коміту до середовища, потім відкат на попередню версію й повторний запуск. Дивимося, чи відтворюється збірка за того самого коду і як поводяться права й секрети.
-
Передача документації. Віддаємо схему контуру, конфігурації агентів, політики запуску та інструкції для чергових: як розібрати збірку, що впала, як перезапустити крок, як надати доступ новому інженеру.
Що залишається у вас: конфігурації, схеми, регламенти
Ми не залишаємо замовника з працюючим, але незрозумілим конвеєром: конвеєр на Drone CI повністю описується як код у вашому репозиторії, поруч лежать схеми й документація.
Інженер вашої команди зможе змінити крок збірки, додати середовище або відкотити реліз, не звертаючись до нас.
- Конфігурації збірки — описи кроків і умов запуску: за тегом, за гілкою, вручну. З коментарями, чому порядок саме такий і де точка відкату.
- Політики доступу — хто запускає збірки, хто змінює конфігурацію і хто деплоїть у продакшн; ролі розробника й чергового розведені.
- Схеми інфраструктури — контур цілком: репозиторій, агенти збірки, реєстр образів, кластер і середовища, місця зберігання секретів.
- Регламент відновлення — порядок дій у разі падіння агента, втрати доступу до реєстру або невдалого релізу, з часом на кожен крок.
- Інструкції для команди — як повторити збірку локально, додати новий сервіс у конвеєр, що робити зі збіркою, яка впала вночі.
- Карта секретів і змінних — де лежить значення, хто власник, як і коли ротувати, щоб не шукати це в момент збою.
- Чек-лист приймання — перевірки, за якими ви самі переконуєтеся, що збірка й відкат працюють уже без нас.
Кейс: скоротили збірку й прибрали ручні викладки
До нас прийшов контур продукту: кілька сервісів, спільний сервер збірки й регламент викладки у вікі. Реліз запускався вручну з локальної машини чергового, тому збірка й викатка розтягувалися більш ніж на годину, а результат залежав від того, у кого з команди «працює».
Контур до змін
Медіанна збірка займала близько 38 хвилин: кроки йшли послідовно і щоразу заново тягнули залежності. Автоматичних викладок було менше п’ятої частини, решта — руками, з ручним же відкатом.
Невдалий реліз означав нічне чергування: повернення попередньої версії займало години, бо ніхто точно не пам’ятав, які кроки під час викладки були пропущені.
Що змінили і що отримали
Збірку й викладку перевели в Drone CI: конвеєр описується декларативно й лежить поруч із кодом. Додали кеш залежностей між запусками, розпаралелили незалежні кроки, образи стали незмінними й потрапляють у реєстр під конкретний коміт. Перехід між середовищами йде тим самим конвеєром, викладка стартує за тегом, а не за кнопкою.
Медіанна збірка скоротилася з 38 до 9 хвилин, частка автоматичних викладок виросла до 95%. Відкат — це повторний запуск попереднього успішного конвеєра: пара хвилин замість годин.
Якщо падає перевірка тестів або перевірка готовності подів після розгортання, викладка не доходить до продакшену й середовище залишається на попередній версії — клас відмов «роз’їхалися конфігурації між середовищами» зник зовсім.
Технічні сумніви: секрети, кеш, власні агенти
Перед стартом зазвичай виринає той самий набір прикладних питань: де лежать секрети, чи не ламає кеш відтворюваність, чи потрібні власні агенти і що робити з уже працюючим конвеєром. Нижче — короткі відповіді про те, як ми вирішуємо це в проєктах на Drone CI.
Де зберігаються секрети і хто їх бачить?
Секрети живуть у самому Drone CI — на рівні організації або окремого проєкту, з розбивкою за середовищами. У крок вони підставляються лише на час виконання й маскуються в логах, тому значення не потрапляють ні в репозиторій, ні в зібрані артефакти. Доступ видається за правами учасника, а не всім, хто має доступ до коду.
Кеш прискорює збірку — чи не ламає він відтворюваність?
Кеш ключується за відбитком файла залежностей і цільовою гілкою: змінився маніфест — кеш перезбирається з нуля. Кешуємо лише сторонні залежності й не кешуємо результати своєї збірки, інакше в артефакт може витекти застарілий код.
Для релізних збірок кеш вимикається примусово: довше, зате результат перевірно повторюваний на тій самій ревізії.
Чи потрібні свої агенти або вистачить хмарних?
Хмарних агентів вистачає для типових завдань: збірка, тести, публікація образів. Свої потрібні, коли кроку потрібен доступ у внутрішню мережу, специфічне середовище або коли обсяг залежностей робить вигіднішим тримати кеш поруч із кодом. Починаємо з одного-двох агентів і додаємо в міру зростання паралельних завдань.
Уже працює інший контур — переносити все відразу?
Ні. Працюючий контур не вимикаємо: переносимо по одному репозиторію, обидва існують паралельно, результати збірок порівнюються на тих самих змінах коду. Відкат — повернути тригер на попередню систему, історія й артефакти залишаються на місці. Так перехід не блокує релізи.
Обговоримо задачу: що надіслати для швидкої оцінки
Щоб оцінка була предметною, а не «на око», нам достатньо короткого набору вхідних даних. Дивимося на поточний конвеєр збірки й доставки, середовища й те, як сьогодні викочуються зміни, — із цього складається склад робіт, етапи та строки.
Що надіслати:
- Посилання на репозиторії та права на читання налаштувань конвеєра — побачимо, як організовані збірка, тести й публікація образів.
- Конфігурації збірки й розгортання: файли збірки образів, маніфести Kubernetes, схеми середовищ і змінних.
- Опис середовищ — скільки кластерів, які середовища (розробка, передпродакшн, продакшн), хто і як отримує доступ.
- Схему роботи із секретами й реєстром образів: де зберігаються ключі, як видаються права, чи є розділення за середовищами.
- Поточний ручний процес релізу: скільки часу займають збірка, перевірки й викатка, на якому кроці найчастіше ламається.
- Вимоги безпеки: перевірки уразливостей, підпис образів, розмежування прав, журналювання дій.
- Очікуваний режим релізів: частота викаток, вікна оновлень, вимоги до відкату й допустимого простою.
Окремо потрібен інженер, який проведе по інфраструктурі й відповість на питання під час розбору — це економить тижні листування.
За цими даними ми повернемося з оцінкою задачі та планом впровадження: переведення збірок і викатки на Drone CI у Kubernetes, розбитий на етапи, з відповідальними та строками за кожним.
Чим свої агенти збірки відрізняються від керованих?
Керовані агенти — чужа інфраструктура: ви отримуєте образ, який вам видали, і чергу, якою не керуєте. Свої агенти — вузли під вашим контролем, де образ, доступи й політику утилізації задаєте ви.
Різниця проявляється не в зручності, а в тому, що саме ви можете полагодити, коли збірка стала, і хто відповідає за простій.
Ізоляція визначає, що переживає одну збірку. Одноразовий агент в окремому просторі імен забирає із собою все: кеш пакетів, тимчасові файли, проміжні шари образу — наступне завдання стартує з чистого стану, і підмінити результат чужою збіркою неможливо.
Багаторазовий пул швидший завдяки прогрітому кешу, але потребує дисципліни: очищення томів і робочих каталогів стає вашим завданням.
Контроль над середовищем вирішує, чи дотягнеться збірка до внутрішніх сервісів. На керованих агентах приватний реєстр і база доступні лише через публічний вхід, а секрети живуть у чужому сховищі.
Свої вузли в кластері бачать внутрішні адреси напряму, ключі лежать у вашому сховищі, версія системних бібліотек фіксується вашим образом, а не чужою політикою оновлення.
Зворотний бік — навантаження на команду. Свій контур потребує оновлень рантайму, ротації ключів, масштабування під пікові години й прибирання диска після падінь; керований знімає це, але забирає гнучкість. Ціна підтримання вимірюється годинами інженерів, а не числом вузлів.
На практиці в Drone CI тримають гібрид: керовані агенти — для перевірок і збірки, власні — для викатки й завдань із доступом до внутрішньої мережі.
