Деплой за тегом: де рветься релізний контур
Написав у полі «гілка» слово main і натиснув «запустити» — типовий спосіб випустити реліз. Але гілка — не версія, а рухоме посилання: поки триває збірка, до неї вже влито наступний набір змін, і на стенді опиняється не те, що було в коді на момент старту.
Відтворюваність збірки ламається й усередині: залежності підтягуються з мережі без фіксації, і повторний запуск із того самого коміту дає інший результат.
Розбіжність помічають не відразу. Артефакт релізу збирається заново під кожне середовище, зі своїм набором змінних, і в продакшні опиняється збірка, якої немає ні в сховищі, ні в когось на руках.
З'ясувати, що саме поїхало, нема чим: тега немає, хеш коміту ніде не записано, журнал випуску закрито.
Відкат перетворюється на перезбірку минулого стану з пам'яті, а поки її готують, контур тримається на ручних правках продакшну — вони не проходять перевірки й зникають під час наступного випуску.
Деплой за тегом прибирає цю розвилку. Тег — незмінна мітка на конкретному коміті, і артефакт збирається рівно один раз, прив'язується до тега й перевикористовується в усіх середовищах: той самий вміст проходить тестовий стенд і вирушає в продакшн. Розбираємо, як влаштувати такий контур і де він усе ще рветься.
Що змінюється після переходу на релізні мітки
Поки розгортання йшло з голови гілки, ознакою «що задеплоєно» був останній коміт: у продакшн міг поїхати зріз, який ніхто не перевіряв повністю.
Релізна мітка знімає цю невизначеність — запуск іде від незмінного вказівника в Git, за яким закріплено конкретний зріз коду й налаштувань.
Різниця проявляється не першого дня, а на метриках. Ось що ми звіряємо першого ж тижня після переходу, щоб відрізнити реальний ефект від формального порядку:
- Частка успішних випусків — чи можна для будь-якого інциденту назвати точний зріз, з якого зібрано прод, і чи збігається він із тим, що пройшло перевірки.
- Час відкату — чи є мітка попереднього стабільного випуску, на яку повертаються однією дією: хвилини проти десятків хвилин під час збірки з гілки.
- Кількість інцидентів через невідповідність коду й збірки — чи зникли випадки, коли в артефакт потрапляв код, якого не було в перевіреному зрізі.
- Історія випусків — чи читається вона за мітками: що увійшло, коли, хто підтвердив.
- Контроль версій — чи захищені мітки від перезапису і чи є правило, хто й як їх ставить.
Якщо пункти закрито, випуск відтворюється за міткою, відкат перетворюється на перемикання на попередню, а розбір інциденту починається з конкретного зрізу, а не з пошуку «що ж там було».
Порівняння: деплой за тегом, за гілкою чи вручну
Вибір моделі випуску визначає, що саме потрапляє в прод і наскільки повторюваний результат. Нижче — чотири варіанти, які трапляються найчастіше, з їхніми межами застосовності та ціною, яку вони тягнуть за собою.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Деплой за тегом | Продуктовий контур: мітка вказує на конкретний стан коду, повторний викат тієї самої мітки дає той самий артефакт | Потрібна дисципліна іменування — зайва мітка створює реліз. Погано лягає на часті дрібні правки |
| Деплой за гілкою | Стенди розробки й тестування, де потрібен автоматичний прогін після кожного злиття | У прод іде «те, що накопичилося»: немає явної межі релізу, відкат можливий лише на попередній стан гілки |
| Ручний запуск релізу | Рідкісні регламентовані випуски, випуск у погоджене вікно | Залежить від людини: пропустили запуск — у проді застаріла збірка, історія викатів розрізнена |
| Умовний випуск | Реліз запускається за подією: мітка, зміна в окремому каталозі, закриття задачі | Правила розростаються й конфліктують між собою, їх складніше пояснити команді та перевірити перед викатом |
На практиці підходи не конкурують, а ділять контури: мітка як єдиний вхід у прод, гілка — як швидкий відгук на стендах, ручний запуск — для винятків на кшталт позапланового виправлення.
Умовний випуск має сенс там, де правило просте й перевірне — наприклад, випуск лише за зміни каталогу сервісу. Далі показуємо, як це звести в один конвеєр без дублювання логіки.
Конвеєр релізів у CI/CD: етапи інженерної роботи
Етапи впровадження однакові, який би інструмент збірки не стояв у замовника: спочатку аудит і правила, потім автоматика.
Завдання — щоб випуск запускався тегом, а не зібраним вручну пакетом: тоді версія в продакшні однозначно відновлювана за ідентифікатором, а суперечка «що там зараз розгорнуто» зникає.
- Аудит конвеєра. Інвентаризація гілок, тегів і ручних кроків: де збирається артефакт, як він потрапляє в середовища, які операції робляться руками. На виході — карта розбіжностей між збіркою та випуском.
- Схема версіонування. Фіксуємо формат тега (major.minor.patch і окремий префікс для передрелізів) і правило, який тег веде в тестовий контур, а який — у продуктивний.
- Правила випуску. Захищені теги, права на їх створення, обов'язкові перевірки до публікації, ручне підтвердження на продуктив.
- Налаштування збірки з тега. Один тег — один незмінний артефакт, який не перезбирається під час просування між середовищами.
- Налаштування релізів на деплой. Прив'язка тега до середовища, міграції бази, перевірка живості після викату й автоматичний відкат на попередній тег у разі невдачі.
- Репетиція. Прогін на одному сервісі: заміряємо час від постановки тега до робочого середовища й окремо — час повернення на попередню версію.
- Передача управління. Регламент випуску, опис відкатів і прав доступу, навчання чергової команди замовника.
Що залишається в замовника: конфігурації та регламенти
Передача проєкту — це не архів із вихідними кодами, а робоча система, яку приймальна команда може запустити, змінити й відкотити без участі автора.
Тому до закриття робіт збирається комплект, де в кожного артефакту є власник і зрозумілий сценарій використання, а не лише факт наявності файлу.
- Файли конвеєра — описи збірки й випуску лежать у репозиторії поруч із кодом, а не в налаштуваннях веб-інтерфейсу: зміни проходять рев'ю та версіонуються разом із застосунком.
- Схема конвеєра — від збірки й перевірок до публікації артефакту та викладки, з явно позначеними точками ручного підтвердження й місцями, де випуск зупиняється автоматично.
- Матриця середовищ — які гілки й теги потрапляють у тестовий і промисловий контури, чим відрізняються їхні параметри, як розділено дані й секрети.
- Політики доступу — ролі на запуск випуску й підтвердження викладки в промисловий контур; для автоматики використовуються окремі службові облікові записи замість особистих.
- Регламент випуску — як формується тег, хто має право його поставити і що вважається підставою для випуску, включно зі складом обов'язкових перевірок.
- Інструкція з відкату — покрокове повернення на попередній випуск: які команди, у якому порядку, за який час контур повертається в робочий стан і за якими ознаками відкат запускається.
- Документація конвеєра — де зберігаються секрети й як вони оновлюються, як підключаються залежності, які перевірки блокують, а які лише попереджають.
Комплект вважається прийнятим не за підписом, а за фактом: інженер замовника сам ставить тег, доводить випуск до промислового контуру й виконує навчальний відкат.
Зауваження, знайдені на цьому кроці, закриваємо до передачі — разом зі схемами й регламентом вони залишаються всередині проєкту й не потребують звернень до нас за поясненнями.
Кейс: релізи за мітками замість збірки з гілки
Продуктова команда замовника вела кілька сервісів і збирала релізи прямо з основної гілки.
У випуску не було незмінної точки: стан середовища не можна було описати одним ідентифікатором, тому «повернути як було» означало зібрати заново — а нова збірка з тієї самої гілки могла не збігтися з тим, що реально працювало.
Перед кейсом впровадження заміряли три величини за квартал: випуск займав від 35 до 50 хвилин ручних операцій, кожен четвертий реліз закінчувався відкатом, а приблизно в кожному п'ятому випадку артефакт на середовищі не збігався з кодом гілки — до неї встигали приїхати нові коміти.
Що змінили
Перехід на мітки зробив тег єдиним джерелом релізу. Складальний контур збирає артефакт лише з позначеного коміту в Git і кладе його в незмінне сховище, а викладка в продуктивне середовище з гілки заборонена правилами.
Відкат — не перезбірка, а перемикання на попередню мітку, тією самою командою, що й випуск. Реєстр міток став журналом релізів: за одним ідентифікатором видно, що і коли поїхало.
Результати проєкту
| Метрика | До | Після |
|---|---|---|
| Час випуску | 35–50 хвилин | 6–8 хвилин |
| Відмови випуску | кожен четвертий реліз | один із двадцяти |
| Розбіжності збірки й коду | близько 20% релізів | не відтворюються |
| Повернення до попереднього релізу | близько години | кілька хвилин |
Через півроку команда почала випускати частіше, а не рідше: реліз перестав бути подією з ризиком, а метрики релізів тепер читаються з історії міток, а не збираються вручну за логами.
Що робити, якщо реліз уже збирається з гілки?
Так, перехід на мітки не вимагає переписувати конвеєр. Мітка й гілка — обидва вказівники на коміт, тому кроки збірки, тестів і публікації артефакту залишаються тими самими. Змінюються дві речі: умова запуску і те, звідки береться номер версії.
Основна робота — винести версію із шаблону в параметр. Зараз номер зазвичай обчислюється з імені гілки або проставляється вручну, і саме це заважає запуску за міткою.
Щойно версія приходить ззовні, із самої мітки, конвеєр стає байдужим до джерела запуску, а перемикання зводиться до налаштування тригера.
Впроваджувати це варто поступово, не розриваючи робочу схему. Спочатку запуск за міткою додається паралельно: збірка з гілки продовжує випускати проміжні версії, а мітка запускає релізний прохід за тими самими кроками.
Перші релізи проганяємо в обидва боки й порівнюємо артефакти — склад і контрольна сума мають збігтися, інакше в якомусь кроці зашита залежність від гілки.
Історія при цьому не ламається. Мітки можна проставити на вже випущені коміти заднім числом — старі релізи отримають ті самі позначення, що й нові, і зв'язок «мітка — артефакт — середовище» стане безперервним.
Після цього стабільні релізи йдуть лише за міткою, а гілка залишається інструментом розробки; повернутися до попередньої схеми можна на будь-якому етапі, поки паралельний запуск не вимкнено.
Фінальний крок — правило, що забороняє публікацію в прод без мітки, і заборона перезбірки наявної: одна мітка дає один незмінний артефакт. Знайшли помилку в релізі — випускається нова мітка, а не перезапис старої.
Саме це робить відкат передбачуваним: середовище повертається до конкретного зафіксованого артефакту.
Часті запитання про релізні мітки та відкати
Сумніви щодо релізних міток зазвичай зводяться до чотирьох тем: хто має право випускати, як відкотитися, що з паралельними версіями і чи не доведеться ламати робочу схему. Нижче — як це влаштовано в конвеєрі.
Хто має право ставити релізну мітку?
Право на випуск має обмежене коло ролей: мітку ставить відповідальний, а пряма викладка з робочої гілки закрита налаштуваннями конвеєра. Обійти це правило не можна — перевірки виконуються незалежно від того, хто випускає.
Як відкотитися, якщо реліз виявився поганим?
Артефакт збирається один раз і зберігається незмінним разом із міткою, тому відкат релізу — це викладка попередньої мітки, а не перезбірка. Повернення до робочої версії займає хвилини й не залежить від того, що встигли змінити в гілці.
Чи можна вести кілька версій паралельно?
Так: під кожну лінію підтримки своя гілка й свої мітки, тому виправлення в старій версії не тягне за собою зміни з нової. Паралельні версії живуть на різних середовищах і не заважають одна одній.
Що буде з уже робочою схемою випуску?
Доопрацювання конвеєра йде поетапно: старий спосіб залишається робочим, поки новий не перевірено на бойовому випуску. Перемикання — по одній послузі, з можливістю повернутися назад.
Як довго зберігаються релізні артефакти?
Політика зберігання задається явно: випуски за кожною міткою залишаються доступними для відкату, решта йде за розкладом. Сховище не росте безкінечно.
Обговоримо вашу схему релізів і повернемося з планом
Щоб схема деплою за тегом запрацювала на вашій інфраструктурі, а не залишилася набором правил в окремому репозиторії, потрібен план під ваш поточний процес випуску: як версії присвоюються зараз, хто і в який момент ставить релізний тег, скільки середовищ проходить артефакт і що вважається відкатом.
Опишіть це у вільній формі — достатньо розгалуження, способу збірки й того, де зараз ручні кроки. Наші інженери розберуть схему й повернуться з оцінкою робіт і планом впровадження: що робимо на старті проєкту, що пізніше, що можна залишити як є.
- План впровадження за етапами: розмітка релізних тегів і правила їх появи, збірка артефакту із зафіксованого стану, просування за середовищами
- Схема відкату: повернення на попередній тег без перезбірки, зі збереженням конфігурації середовища й даних
- Політики доступу та підпису: хто має право випускати тег, чим підтверджується справжність артефакту
- Розділення збірки й викату: що перевикористовується між середовищами, де залишаються відмінності в налаштуваннях
- Набір перевірок перед викатом: які автоматичні ворота пропускають реліз, а які потребують підтвердження
- Документація й передача: опис схеми випуску, інструкції для чергового, розбір типових збоїв
Опишіть завдання — повернемося з оцінкою робіт і планом, де зафіксовані етапи, зони відповідальності та порядок запуску.
