Планування релізу

Деплой — це не реліз

Деплой — технічна подія: новий код працює на production-інфраструктурі. Реліз — продуктова подія: користувачі тепер можуть робити те, чого не могли раніше. Більшість організацій вважає це одним моментом, і саме тому «день релізу» такий страшний: усі технічні й усі продуктові ризики приходять разом, опівночі, у п’ятницю, яку хтось обрав місяці тому.

Розділення змінює саму суть плану релізу. Код потрапляє в production постійно — прихований і неактивний за прапорцем. Реліз стає окремим зворотним рішенням: увімкнути для 1% користувачів, подивитися на цифри, увімкнути для всіх — або вимкнути за секунди, без відкату, хотфіксу й авральної наради.

Чотири стратегії релізу

Ці підходи поєднуються, а не конкурують, і працюють на різних рівнях. Blue-green і canary вирішують, до якої версії коду потрапить запит, — це інфраструктурна справа, зазвичай власність тих, хто веде платформу. Feature flags вирішують, яку поведінку з цього коду отримає конкретний користувач, — це продуктова справа. Зріла схема деплоїть постійно, маршрутизує через canary на рівні інфраструктури й керує аудиторією через прапорці на рівні продукту.

Дві суміжні техніки варто назвати, бо вони розв’язують те, чого чотири вищі не розв’язують. Dark launch запускає новий шлях коду на реальному трафіку, не показуючи результату нікому: ви порівнюєте його вивід чи затримку зі старим шляхом і дізнаєтеся, чи спрацював би він. Rolling update замінює інстанси невеликими партіями — саме так за замовчуванням чинить більшість оркестраторів; це дешевше за blue-green, але обидві версії одночасно обслуговують трафік, і код має це витримувати.

Чотири види прапорців, чотири терміни життя

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

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

Коли відкат недоступний

Плани релізу звично вписують «відкотити» як пом’якшення будь-якого ризику, і для stateless-коду це чесно. Щойно реліз торкається постійних даних, це зазвичай перестає бути правдою — і план тепер описує страхувальну сітку, якої немає.

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

Техніка, що лишає обидва варіанти відкритими, — expand and contract. Замість однієї міграції, яка змінює форму, ви робите три релізи: expand — додати нову колонку, поки стара працює й пишуться обидві; migrate — заповнити дані й перевести читання на нову; contract — прибрати стару, коли з неї ніхто не читає. Кожен крок оборотний окремо, а необоротний відбувається останнім, коли новий шлях уже кілька днів працює в production.

Що насправді має перевіряти go/no-go

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

• Чи визначено шлях назад — вимкнути прапорець, рухатися вперед або відпрацьований шлях для даних — і чи хтось його реально проходив?
• Який сигнал за десять хвилин скаже, що стало гірше, і чи хтось за ним стежить?
• Хто поза інженерією має дізнатися раніше за користувачів — підтримка, продажі, ті, хто відповідає на дзвінки?
• Чи стається в цьому релізі щось необоротне і чи можна перенести це в наступний?
• Якщо піде не так у найгірший правдоподібний момент — хто доступний і як до нього достукатися?

Вимірюйте процес, а не план

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

• Частота деплоїв

  Як часто код потрапляє в production. Найкращі команди деплоять на вимогу, кілька разів на день.

• Час від коміту до production

  Від коміту до роботи в production. Менше години на elite-рівні; місяці на низькому.

• Частка невдалих змін

  Частка деплоїв, що спричиняють деградацію сервісу. У найкращих — від одиниць відсотків до приблизно 15%.

• Час відновлення

  Скільки триває деградація сервісу. Менше години — орієнтир elite, і це важливіше за уникання збоїв узагалі.

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

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

Як це виявляється в реальній поставці

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

Де воно вироджується

• Комітет, що затверджує деплої, додає затримку, не додаючи інформації, якої не дали тести.
• Пакування місяця змін в один реліз — кожен збій стає складно віднести до причини.
• «Відкотити» як пом’якшення для релізу, що виконує необоротну міграцію.
• Прапорці без власника й дати згасання тихо стають постійними розгалуженнями в коді.
• Canary без автоматичного порівняння — це повільніший big bang із гарнішою назвою.
• Частота деплоїв як ціль дає більше деплоїв, а не більше цінності.

Коли це застосовувати

Пов’язані сторінки

• МенеджментGit-стратегія гілкуванняGit-стратегія гілкування — це домовленість про те, як команда розділяє роботу на гілки і як знову їх зводить. Вибір виглядає справою смаку, але нею не є: єдина змінна, що надійно передбачає біль, — скільки живе гілка до злиття, і кожна стратегія насправді є позицією щодо цього одного числа. На цій сторінці — чотири моделі, які вам трапляться, що робить короткі гілки можливими і коли релізні гілки справді виправдовують свою ціну.
• МенеджментChangelogChangelog — це впорядкований, зрозумілий людині запис того, що змінилося в кожному релізі. Уся його цінність — у тому, що він написаний для читача, який вирішує, чи оновлюватися. Саме тому згенероване звалище комітів, хай навіть повне, не є changelog. На цій сторінці — шість заголовків, що обіцяє номер версії, депрекація і як далеко чесно може завести автоматизація.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його під вимірюванням. Kanban не додає ні ролей, ні спринтів. Він додає одне правило — обмеження кількості задач, над якими можна працювати одночасно, — і саме це обмеження змушує працювати все інше в методі. На цій сторінці ми розберемо дошку, метрики, сім регулярних зустрічей, які метод визначає, і те, як на практиці встановити це обмеження.