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

План релізу на одному екрані — готовий

Більшість тих, хто шукає планування релізу, хоче побачити план, який працює. Ось один — для інтернет-магазину, що проходить крізь сторінки розділу «Декомпозиція»: реліз, що відкриває клієнтам «Повторне замовлення з історії», фічу 1 епіка про повторні замовлення. Код для неї вже кілька тижнів потрапляє в production вимкненим. Тож план не про дату деплою. Він про те, хто бачить фічу, в якому порядку, що її зупинить і як її знову вимкнути. Наступні розділи посилаються на рядки за номерами.

1. 1.Що виходить, а що — ні

   1. 1.1Повторне замовлення з історії — історії 1.1–1.4 епіка про повторні замовлення, за release-прапорцем reorder-from-history
   2. 1.2Власник прапорця — продакт-менеджер команди, а строк його життя спливає 18 грудня
   3. 1.3Не в цьому релізі: збережені кошики, фіча 2, — перенесено на січень, а не втиснуто перед заморозкою
   4. 1.4Один рядок changelogchangelogперелік змін за версіямиФайл, зазвичай CHANGELOG.md, що перелічує помітні зміни кожної версії програми, найновіші першими, згруповані як додане, змінене, задепрековане, видалене, виправлене й безпека. Його пишуть для того, хто вирішує, чи оновлюватися, — тому вивантаження повідомлень комітів таким файлом не вважається.Докладніше в статті →Усі терміни на кожну історію, написаний до етапу 3.3, — для клієнтів і для підтримки

2. 2.Схема й дані

   1. 2.1Expand: nullable-колонка reorder_source у таблиці замовлень, задеплоєна 20 жовтня — за два тижні до того, як фічу хтось побачить
   2. 2.2Без дозаповнення: минулі замовлення читаються із сервісу історії замовлень, enablerenablerробота, що уможливлює наступнуЕлемент беклогу, якого не просив жоден користувач, але який уможливлює наступні: дослідження, архітектура, інфраструктура чи відповідність вимогам — чотири типи в SAFe. Його називання дає цій роботі змогу відкрито конкурувати за потужність, а не ховатися в оцінках user stories.Докладніше в статті →Усі терміни 4 на сторінці про епіки
   3. 2.3У цьому релізі нічого не видаляють і не перейменовують; будь-який крок contract чекає кінця заморозки

3. 3.Етапи — кожен відкривається, лише якщо попередній пройшов усі пороги з групи 5

   1. 3.1Dark launch з понеділка 26 жовтня: кожен перегляд історії замовлень викликає «Повторити» у фоні й відкидає результат; помилок менше 0,1%, p95p99час відгуку для найповільнішихЧас відгуку, в який вкладаються 99% запитів; p95 і p50 — та сама величина для 95% і для медіани. Середнє приховує саме ті запити, через які люди йдуть, — тому дивляться на ці числа, а не на нього.Усі терміни менше 300 мс
   2. 3.2Акаунти працівників, близько 200, у понеділок 2 листопада
   3. 3.31% постійних клієнтів у середу 4 листопада, після go/no-go, — до понеділка, щоб у вибірку потрапили вихідні
   4. 3.410% у понеділок 9 листопада
   5. 3.550% у середу 11 листопада — знову з вихідними
   6. 3.6100% у понеділок 16 листопада; якщо до середи 18 листопада цього не досягнуто, прапорець лишається там, де є, до 2 грудня

4. 4.Шлях назад

   1. 4.1Вимкнути прапорець: черговий інженер або продакт-менеджер, з консолі прапорців, діє менш ніж за хвилину; відрепетирувано на stagingstagingсередовище-репетиціяКопія продакшену, на якій зміни пробують до того, як їх зустрінуть справжні користувачі. Скільки вона доводить, повністю залежить від того, наскільки вона схожа на продакшен: staging із десятою частиною даних, без реального трафіку й з іншою конфігурацією показує, що код запускається, і майже нічого більше.Усі терміни 30 жовтня
   2. 4.2Дефект у коді: виправлення вперед через звичайний пайплайн, 25 хвилин; попередня збірка лишається придатною до деплою, бо 2.1 лише додала колонку
   3. 4.3Що не скасувати: замовлення, оформлені й оплачені через «Повторити», лишаються оформленими; у підтримки є шаблон повернення коштів для замовлення, якого клієнт не хотів

5. 5.Сигнали — і хто за ними стежить

   1. 5.1Частка успішних оплат щонайменше 97,5% у групі з прапорцем — committed key result зі сторінки про OKROKRObjectives and Key Results — ціль із вимірюваними результатамиМетод постановки цілей, що поєднує одну якісну ціль із двома-п’ятьма вимірюваними key results, які доводять, що її досягнуто; їх ставлять і переглядають щокварталу. Він перестає працювати, коли key results стають списком задач або оцінки впливають на оплату.Докладніше в статті →Усі терміни; алерт, а не дашборд
   2. 5.2Натискання «Повторити», що закінчуються помилкою: менше 0,5%
   3. 5.3Конверсія оформлення в групі з прапорцем проти групи без нього — продакт-менеджер читає щоранку
   4. 5.4Звернення в підтримку з тегом «reorder» — керівник підтримки рахує щоранку

6. 6.Люди й дати

   1. 6.1Власник релізу — продакт-менеджер, який відкриває кожен етап і може закрити будь-який із них
   2. 6.2Етапи відкривають з понеділка по четвер, до 14:00, з черговим інженером до 20:00
   3. 6.3Підтримку інструктують 30 жовтня: FAQ на одну сторінку, шаблон повернення, рядки changelog
   4. 6.4Go/no-go у вівторок 3 листопада, п’ятнадцять хвилин, перед етапом 3.3 — його п’ять питань є в розділі про шлях назад
   5. 6.5Передсезонна заморозка змін з 19 листопада до 1 грудня (Black Friday — 27 листопада): жоден етап не рухається вперед, але вимкнути прапорець дозволено завжди

7. 7.Готово, коли

   1. 7.1Прапорець чотирнадцять днів на 100% і жодного разу не вимикався
   2. 7.2Прапорець і старий шлях коду видалено до 18 грудня, після заморозки
   3. 7.3Випереджальні показники передано на рев’ю епіка, яке вирішує долю фічі 3

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

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

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

Це розділення має коротку історію. Джез Гамбл і Девід Фарлі зробили його центром книжки «Continuous Delivery» (2010): кожна зміна, що пройшла пайплайн, придатна до релізу, а випустити її — бізнесове рішення. Facebook показав крайній випадок ще у травні 2008 року. Чат будували, щоб увімкнути для всіх приблизно 70 мільйонів користувачів одразу, тож кілька тижнів перед тим живі сторінки тихо генерували чат-трафік без жодного видимого інтерфейсу. Сервери зустріли справжнє навантаження раніше за будь-якого користувача. Ця техніка зветься dark launch, і рядок 3.1 плану — саме вона.

Фіксована дата чи фіксований обсяг — ритм, у якому живе реліз

Ще до будь-якого викочування план релізу відповідає на питання, яке часто пропускають: що фіксоване — дата чи вміст? Зафіксувати обидва — класичний спосіб провалити обидва. Єдиною змінною лишається якість, а її ніхто не записує як рішення. Робочих відповідей три.

Release train працює, бо прибирає найдорожчу розмову в розробці: «можна почекати ще два дні на мою фічу?» Відповідь завжди «ні», а наступний потяг ніколи не далеко, тож сперечатися немає потреби. Фіча, не готова на момент відгалуження, лишається вимкненою, і потяг вирушає без неї. Ціна в тому, що велику фічу треба будувати так, щоб вона могла проїхати кількома потягами вимкненою, — а це знову розділення деплою й релізу. SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни масштабує ту саму ідею на цілий підрозділ: Agile Release TrainAgile Release Train5–12 команд, що планують і постачають разомУ SAFe — довгоживуча група з пʼяти-дванадцяти agile-команд, зазвичай 50–125 осіб, які разом планують на PI Planning, працюють до однакових меж ітерацій і щоітерації інтегрують свою роботу. Її варто проводити навколо шляху, яким продукт іде до клієнтів; потяг, проведений навколо наявних відділів, координує їх, нічого не змінюючи.Докладніше в статті →Усі терміни планує разом на кожен Planning Interval, зазвичай від восьми до дванадцяти тижнів, — а його власна формула «develop on cadence, release on demand» тримає план і реліз окремо.

Прогноз релізу з фіксованим обсягом

Коли вміст фіксований, дату доводиться прогнозувати, і чесний прогноз — це діапазон. Арифметика, яку Майк Кон виклав у книжці «Agile Estimating and Planning» (2005), досі працює. Поділіть залишок обсягу на найнижчу й на найвищу швидкість, яку команда справді мала. 120 пунктів залишку при 18–26 пунктах за спринт — це від п’яти до семи спринтів, а не 5,6. Називайте діапазон і кажіть, що його звузить.

Колись планування релізу було частиною самого Scrum. Scrum Guide 2010 року описував зустріч із планування релізу та release burndown. Редакція липня 2011 року прибрала обидва, і жодна наступна їх не повернула: кожен спринт має давати придатний до релізу інкремент, тож як групувати релізи, вирішує команда. Extreme ProgrammingExtreme Programmingagile-метод, що починається з інженеріїAgile-методологія кінця 1990-х, збудована навколо інженерних практик: розробка від тестів, парне програмування, безперервна інтеграція, рефакторинг і невеликі часті релізи. Від неї походить більшість того, що тепер називають технічною гнучкістю, і команда, яка переймає події Scrum без цих практик, зазвичай бачить, як її спринти сповільнюються.Усі терміни це зберіг. Його planning game у книжці Кента Бека «Extreme Programming Explained» (1999) має план релізу з історій над планом кожної ітерації.

Стратегії викочування — від усіх одразу до одного відсотка

Стратегія викочування вирішує, хто першим зустріне нову версію. Стратегії відрізняються тим, що рухається — сервери, трафік чи користувачі, — і тим, як працює шлях назад. Вони поєднуються, а не конкурують: магазин деплоїть через rolling update, а фічу відкриває прапорцем.

Назву blue-green близько 2005 року дали Деніел Терхорст-Норт і Джез Гамбл, а Мартін Фаулер описав техніку в березні 2010-го. Canary-реліз позичає образ шахтарської канарки: мала група першою зустрічає небезпеку. Кільця застосовують ту саму ідею до людей, а не до трафіку, і так Microsoft випускає Azure DevOps: спершу кільце власних інженерів, решта світу — останньою. Дві суміжні техніки розв’язують те, чого не розв’язують інші. Dark launch проганяє новий шлях на реальному трафіку, не показуючи результату, — як рядок 3.1. Rolling update — те, що за замовчуванням робить більшість оркестраторів: дешевше за blue-green, але обидві версії обслуговують трафік одночасно.

Застосунки в сторах неможливо викочувати через canary у звичному сенсі, бо версію на телефоні не повернеш назад. Поетапний реліз Apple (phased releasestaged rolloutоновлення для дедалі більшої частки користувачівВипуск оновлення спершу для невеликої частки користувачів — 1%, потім 5%, 20%, усі — з перевіркою частоти падінь і помилок перед кожним кроком, щоб поганий реліз дійшов до небагатьох, а не до всіх. Воно обмежує, до скількох людей дійде поганий реліз, а не те, чи дійде він узагалі: у магазинах застосунків зупинене розгортання не забирає оновлення в тих, хто його вже має.Усі терміни) розподіляє оновлення серед користувачів з автооновленням за сім днів — 1, 2, 5, 10, 20, 50 і 100 відсотків — і його можна поставити на паузу сумарно до 30 днів. Вручну завантажити версію може будь-хто. Staged rollout у Google Play можна зупинити, але ті, хто вже отримав версію, лишаються на ній. У мобільному плані релізу вимкнути ще можна лише прапорець усередині застосунку.

Canary потребує порівняння, а не дашборда

Canary захищає лише тоді, коли щось автоматично порівнює його з тим, що він замінює, — до наступного кроку. У квітні 2018 року Netflix і Google відкрили код Kayenta — «суддю» canary, яким Netflix користувався всередині компанії. Його дизайн містить деталь, яку більшість команд пропускає: canary порівнюють не з production. Свіжу базову групу (baseline) зі старою версією запускають у той самий момент і того самого розміру. Сервери, що працюють давно, відрізняються від нових прогрітим кешем, пам’яттю й з’єднаннями, і ця різниця заглушила б ту, яку ви шукаєте.

«Суддя» оцінює canary від 0 до 100 відносно baseline за обраними метриками. Успіх просуває його далі, проміжна оцінка звертається до людини, а провал відкочує. План магазину застосовує ту саму логіку через прапорець. Група з прапорцем і група без нього — це canary і baseline, тому рядок 5.3 порівнює їх, а не читає одне число окремо.

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

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

Перші два тимчасові, другі два — ні. Плутанина в будь-який бік шкодить. Залишений release toggle стає нетестованим шляхом коду, який тихо гниє. Permission toggle, записаний у «борг прапорців», видалить хтось під час прибирання — разом із платним тарифом. Рядок 1.1 плану — release toggle, тож рядки 1.2 і 7.2 дають йому власника й дату смерті.

Годжсон перелічує способи, якими команди тримають тимчасові прапорці тимчасовими. Задача на видалення потрапляє в беклог того ж дня, коли прапорець створено. Прапорець отримує дату згасання. Тест-«бомба уповільненої дії» валить збірку, щойно прапорець переживе цю дату. Або система має ліміт на те, скільки прапорців може нести одночасно. Рядок 7.2 — другий із цих способів. Третій — той, що працює й тоді, коли всі зайняті.

Шлях назад — і коли його немає

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

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

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

План магазину використовує лише перший крок. Рядок 2.1 додає колонку, якої не читає жоден старий код, тож попередню збірку досі можна задеплоїти (4.2). Рядок 2.3 відсуває все руйнівне за межі заморозки. Класична пастка тут — перейменування. Воно виглядає як одна нешкідлива міграція, а насправді це кроки expand і contract, зроблені одночасно, без релізу між ними.

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

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

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

Чотири релізи, що пішли не так, і рядок, якого бракувало кожному

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

Knight Capital, 2012 — прапорець із минулим

Knight Capital була одним із найбільших трейдерів акцій у США. У липні 2012 року компанія готувала свій маршрутизатор ордерів SMARS до нової програми Нью-Йоркської фондової біржі для роздрібних ордерів. Новий код повторно використав прапорець, що колись вмикав «Power Peg» — функцію, якою не користувалися з 2003 року, але так і не видалили, і зламану з 2005-го, коли код, на який вона спиралася, перенесли, а її саму не перетестували. З 27 липня технік вручну копіював новий код на вісім серверів. Один пропустили, і ніхто другий цього не перевірив.

1 серпня ринок відкрився, надійшли ордери з увімкненим прапорцем, і восьмий сервер запустив Power Peg. До відкриття пішло дев’яносто сім автоматичних листів «Power Peg disabled»; їх не проєктували як алерти, і ніхто на них не відреагував. Приблизно за 45 хвилин система здійснила 4 мільйони угод зі 154 акціями — понад 397 мільйонів акцій, — і Knight втратила понад 460 мільйонів доларів. Одна зі спроб виправити ситуацію її погіршила. Команда видалила новий код із семи правильних серверів, і Power Peg опинився за прапорцем на всіх восьми. Постановою SEC від 16 жовтня 2013 року фірму оштрафували на 12 мільйонів доларів.

TSB, 2018 — вікенд без шляху назад

TSB, британський банк із приблизно 5,2 мільйона клієнтів, переходив із платформи, яку орендував у Lloyds Banking Group, на Proteo4UK — її збудував ІТ-підрозділ нової материнської компанії, Sabadell. Метод Sabadell — одна міграція за вікенд, і TSB застосував його до більшості даних: так дешевше, а міграція за продуктами зламала б клієнтам єдиний погляд на їхні рахунки. Міграція відбулася 20–22 квітня 2018 року, і дані перенеслися правильно. Потім платформа відмовила в онлайн- і мобільному банкінгу, телефонному банкінгу й відділеннях, і до звичної роботи TSB повернувся лише 10 грудня.

Остаточне повідомлення регуляторів від 20 грудня 2022 року називає дві речі, заради яких існує план релізу. Шляху назад не було: після міграції відкат був «по суті неможливим». А докази для рішення «go» включали лист постачальника, чиї підтвердження були «спрямованими в майбутнє заявами про добрі наміри чи очікування, а не констатацією фактів», здебільшого із застереженнями про ще не проведені тести. Далі за рік — 225 492 скарги, £32,7 млн компенсацій і штрафи FCA та PRA на £48,65 млн.

CrowdStrike, 2024 — конфігурація теж є релізом

Рано-вранці 19 липня 2024 року CrowdStrike надіслала оновлення контенту — Channel File 291 — своєму сенсору Falcon на Windows. Це була конфігурація, а не код, і конфігурація йшла на кожен сенсор онлайн одразу. Новий шаблон визначав 21 поле вводу, а сенсор подавав 20, і читання 21-го валило Windows. Файл замінили через 78 хвилин. За оцінкою Microsoft, постраждали 8,5 мільйона пристроїв на Windows, і багато з них довелося лагодити вручну, машину за машиною.

Аналіз першопричин від 6 серпня 2024 року відповідає планом релізу. Кожен новий екземпляр шаблону тепер проходить поетапне розгортання: спершу canary, далі кільце за кільцем, і після кожного — час витримки, поки читають телеметрію. Клієнти також можуть обирати, куди й коли приходять оновлення контенту. Це група 3 плану, застосована до даних. Файл, що змінює поведінку, — це реліз, хоч як його називає інструмент деплою.

Google Cloud, 2025 — прапорець, якого не було

29 травня 2025 року Google додав перевірку квотної політики до Service Control — сервісу, що перевіряє авторизацію, політики й квоти для запитів до сервісів Google Cloud. Новий шлях коду не мав обробки порожніх полів і не мав feature flag, і два тижні його ніщо не викликало. 12 червня зміну політики з ненавмисно порожніми полями записали в глобальне сховище, і вона, за словами Google, «реплікувалася глобально за секунди». Кожен регіон одночасно наткнувся на нульовий вказівник, і запити падали з 10:49 до 13:49 за тихоокеанським часом.

Звіт Google каже це прямо: «Якби це було захищено прапорцем, проблему спіймали б на staging». Його зобов’язання — план релізу у двох рядках. Кожна зміна критичного бінарника має бути захищена прапорцем і вимкнена за замовчуванням. І кожну систему, що споживає глобально репліковані дані, мають перевірити. Друге зобов’язання — знову урок CrowdStrike: поетапне викочування коду нічого не дає, якщо дані, що його запускають, приходять усюди одразу.

Вимірювання процесу — і де він вироджується

DORA — дослідницька програма, яку тепер веде Google Cloud, — щороку з 2014-го публікує звіт про поставку програмного забезпечення. Її чотири ключові метрики 2024 року стали п’ятьма. Час від коміту до production, частота деплоїв і час відновлення після невдалого деплою описують пропускну здатність. Частка невдалих змін і нова частка переробок (rework rate) описують нестабільність. Rework rate — це частка деплоїв, яких не планували і які зробили, щоб виправити баг, видимий користувачам.

Два застереження дають самі звіти. Кластери 2024 року — не драбина: середній кластер повідомив нижчу частку невдалих змін (10%), ніж високий (20%), тож деякі команди міняють швидкість на стабільність, а рівні — це знімки відповідей одного року, а не цілі. А 2025 року DORA взагалі відмовилася від чотирьох рівнів і замінила їх сімома архетипами команд, які враховують ще й вигорання, тертя та результати продукту. Висновок, що тримався весь цей час, — той, на якому стоїть планування релізу. Швидкість і стабільність ідуть разом, бо малі зміни легше зрозуміти й скасувати.

Один висновок варто процитувати кожному, хто проєктує комітет із релізів. У книжці «Accelerate» (2018) Ніколь Форсгрен, Джез Гамбл і Джин Кім пишуть, що зовнішні затвердження — менеджером чи комітетом зі змін (change advisory board) — негативно корелювали з часом поставки, частотою деплоїв і часом відновлення та ніяк не корелювали з часткою невдалих змін. Затвердження ззовні команди сповільнювало поставку й не робило її безпечнішою. Тому go/no-go з рядка 6.4 відбувається всередині команди, триває п’ятнадцять хвилин і стосується того, чого не знає пайплайн.

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

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

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

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

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

• МенеджментGit-стратегія гілкуванняGit-стратегія гілкування — це домовленість про те, як команда розділяє роботу на гілки і як знову їх зводить. Вибір виглядає справою смаку, але нею не є: змінна, що передбачає біль, — скільки живе гілка до злиття, і кожна модель — це позиція щодо цього числа плюс правило, звідки беруться релізи й виправлення. Сторінка починається з шести моделей на одному екрані й п’яти питань, що обирають між ними; далі — час життя гілки, звідки взялася кожна модель і що її автори сказали згодом, релізні гілки й шлях виправлення, що робить короткі гілки можливими, merge проти rebase проти squash і де все це вироджується.
• МенеджментChangelogChangelog — це впорядкований, зрозумілий людині перелік помітних змін у кожній версії програми, написаний для того, хто вирішує, чи оновлюватися. Саме через цього читача вивантаження повідомлень комітів, хай яке повне, changelog не є. Сторінка починається з готового changelog; далі — документи, які з ним плутають, що обіцяє номер версії, як написати запис, депрекація, як далеко чесно заходить автоматизація, чотири релізи, де проблемою був рядок changelog, і де практика вироджується.
• ІнфраструктураCI/CDБезперервна інтеграція — це не сервер, що ганяє ваші тести, а звичка зливатися в одну спільну гілку достатньо часто, щоб конфлікти лишалися малими; автоматизація існує, щоб зробити цю звичку безпечною. Безперервна доставка — друга половина: один артефакт, зібраний один раз і просунутий середовищами без перезбирання. На цій сторінці — як упорядкувати етапи, чому нестабільний тест руйнує авторитет конвеєра, чим насправді торгують стратегії розгортання і які чотири числа кажуть, чи все це працює.