У подкасті The Pragmatic Engineer головний герой розмови — Роберт Еріз, principal engineer в Octopus Deploy і фахівець із CI/CD та систем розгортання. Ще на початку 2010‑х він відповідав за великомасштабні деплойменти у Skype, а останні роки проєктує процеси доставки ПЗ для сотень різних команд. На основі цього досвіду він доволі приземлено описує, як працює прогресивна доставка у реальних продуктах: від канарних релізів «на Нову Зеландію» до blue‑green і фічетоглів, які часто виявляються сильнішими за будь‑який сценарій з версіями.
Цей текст — самостійний розбір підходів до прогресивної доставки, без необхідності знати попередні частини розмови.
Від continuous delivery до progressive delivery
У класичній моделі continuous delivery основна мета — завжди мати зміни в стані «готові до деплою». Код регулярно інтегрується, проходить тести, автоматично потрапляє в dev, staging і, за рішенням команди чи за графіком, — у production. Реліз відбувається переважно «одним ударом»: нова версія потрапляє до всіх користувачів, як тільки її розгорнули.
Прогресивна доставка — наступний крок цієї еволюції. Її суть Еріз формулює як випуск змін «у більш контрольований спосіб», зазвичай через такі техніки, як канарні деплойменти. Ідеться не про інший тип CI/CD‑системи, а про усвідомлену стратегію зниження ризику в production: розгортати, спостерігати, поступово збільшувати охоплення, мати простий шлях «загальмувати».
У практиці це виливається у три основні підходи: канарні розгортання, blue‑green і фічетогли. Кожен має свою зону застосування, але в сучасних продуктових командах саме фічефлаги часто стають базовим інструментом.
Канарні деплойменти: чому Нову Зеландію обрали «тестовим» ринком
Один із найживіших прикладів прогресивної доставки з досвіду Еріза — деплойменти в Skype для web. Команда працювала у великій корпорації з усіма типовими атрибутами: дорадчі ради по змінах, формальне погодження релізів раз на тиждень, чіткі вікна деплойментів. Водночас інфраструктура вже тоді дозволяла «штовхати» новий код у production значно частіше.
Щоб розігнути цю бюрократичну пружину, команда фактично влаштувала собі власну continuous delivery‑схему з елементами прогресивної доставки. Зміни потрапляли у staging, проходили кілька рівнів тестів — і після цього розгорталися у production, але не одразу для всього світу.
Роль канарки виконувала Нова Зеландія. Саме ця країна стала «тестовою аудиторією» з кількох причин, які Еріз перераховує майже з посмішкою:
Нова Зеландія — перша країна значного розміру, що входить у новий день за часовим поясом. Це давало зручне вікно: коли в Європі й США ще ніч або глибокий вечір, у Новій Зеландії вже працюють користувачі, і команда може спостерігати за поведінкою системи.
Англомовна аудиторія спрощувала обробку багрепортів і звернень.
Ринок достатньо малий, щоб інциденти не перетворювалися на глобальну кризу, але водночас репрезентативний.
Технічно канарний деплоймент виглядає так: версія 2 сервісу запускається поруч із версією 1; мережевий рівень (traffic manager, load balancer) спрямовує невеликий відсоток трафіку на нову версію; далі частка поступово збільшується. Важлива умова — наявність зрілої спостережності: метрики, логи, алерти мають дозволити вчасно побачити проблеми й знизити частку трафіку або повністю повернутися до попередньої версії.
Мета канарних деплойментів — не в «красивій схемі», а в реальному випробуванні нової версії на живому трафіку в контрольованому сегменті. Новозеландський кейс показав Ерізу, наскільки потужною може бути така тактика, коли команда хоче рухатися швидше за формальні процеси, але не готова ризикувати всією глобальною аудиторією.
Blue‑green: дві версії поряд і миттєве перемикання
Ще одна популярна стратегія прогресивної доставки — blue‑green‑деплойменти. У цій моделі є два повноцінні середовища: одне (blue) обслуговує весь production‑трафік, друге (green) розгорнуте паралельно, але поки що «тіньове».
Нова версія застосунку розгортається у green‑середовищі. Команда має можливість:
перевірити працездатність;
прогнати додаткові тести;
провести ручну валідацію через прямий доступ (наприклад, за окремою IP‑адресою чи доменом).
Коли впевненість достатня, трафік просто перемикають з blue на green. Ззовні це виглядає як миттєве оновлення для всіх користувачів — фактично «канарка на 100%», але з попередньою ізольованою перевіркою.
Blue‑green особливо корисний там, де важливо уникати cold starts і довгого прогріву: нова версія вже «на ногах», прогріта, з ініціалізованими кешами чи іншими ресурсами. Це підхід про контроль і передбачуваність, але все одно його одиниця змін — цілий застосунок, а не окремі фічі.
Чому фічетогли часто сильніші за канарки
Попри симпатію до канарних і blue‑green‑деплойментів, Еріз доволі чітко формулює свою позицію: у більшості випадків «найкорисніша стратегія прогресивної доставки — це фічетогли». Тобто feature flags / feature toggles — незалежно від термінології.
Ключова відмінність — у «одиниці зміни». Для канарного чи будь‑якого версійного деплойменту нею є весь застосунок: якщо з моменту попереднього релізу було 20 комітів, канарний реліз тестує всі 20 одразу, а не тільки ту функцію, яку команда хотіла б контролювати. Це підвищує ризик: валідується пакет змін, а не конкретна можливість.
Фічетогли роблять одиницею зміни окремі гілки логіки — аж до «одиничних рядків коду». Решта системи залишається незмінною, і це радикально знижує площу ризику.
Гранулярність контролю — ще одна сильна сторона. Через фічетогли можна задати складні правила: вмикати фічу для користувачів певного ринку, типу акаунта чи поведінки (на кшталт «клієнти з Німеччини з певним продуктом у кошику»). Досягти подібної точності через мережеве роутинг‑правило значно складніше.
Нарешті, саме фічетогли дають найкращий досвід «ролбеку» у прогресивній доставці. Відкат канарного деплойменту зазвичай означає повний повернення до попередньої версії: це хвилини (або більше) на перекат, повний redeploy, пов’язаний із інфраструктурою та артефактами.
Фічефлаг вимикається за секунди — часто буквально натисканням кнопки в адмінці або API‑викликом. Зміна набирає чинності миттєво, без переінсталяції застосунку. Це повністю змінює психологію чергового та on‑call‑інженера: замість паніки й гарячих патчів достатньо «перекрити фічу», зупинити кровотечу і спокійно шукати причину.
Декуплінг деплою і релізу: головний бонус фічефлагів
Ще один аргумент Еріза на користь фічетоглів — те, як вони змінюють саму модель релізів. У версійній логіці деплой і реліз жорстко пов’язані: щойно нова версія задеплоєна, усі фічі в ній автоматично «в ефірі». Командам доводиться підлаштовуватись під часові вікна розгортання, координуватися з іншими командами, стежити за логами саме в цей момент.
З фічетоглами деплой і реліз розриваються в часі. Застосунок із новим кодом можна вивантажити в production у понеділок, але реальний запуск фічі зробити у вівторок вранці, коли команда онлайн, аналітика відкрита, а лог‑панелі під рукою. Можна навіть дати кільком людям з команди або обмеженому пулу користувачів ранній доступ, перш ніж поширювати зміни на всіх.
Це робить реліз продуктовою подією, а деплоймент — рутинною технічною операцією. Саме так Еріз описує «справжню користь» від фічетоглів: вони дозволяють керувати моментом і масштабом активації змін незалежно від того, коли й як ці зміни потрапили в production.
Де канарки й версійні деплойменти все одно незамінні
Попри прихильність до фічефлагів, Еріз не зводить прогресивну доставку лише до них. Він прямо зазначає: версійні деплойменти через канарки чи blue‑green залишаються дуже корисними, особливо для змін інфраструктури, де немає сенсу або можливості будувати фічетогл на рівні коду.
Це стосується, наприклад:
змін у конфігурації середовища;
оновлень компонентів платформи;
частини складних міграцій баз даних.
Особливо гостро питання постає навколо змін схеми БД. Саме вони, за спостереженнями Еріза, «велика проблема для будь‑якої прогресивної доставки» й місце, де багато команд стикаються з межами своїх підходів.
«Ролбеків не існує»: прогресивна доставка й рух лише вперед
Обговорюючи прогресивну доставку, Еріз неминуче переходить до теми ролбеків. Він помічає парадокс: багато команд говорять про ролбек як про стандартний інструмент безпеки, але варто запитати їх, що вони роблять у випадку зміни схеми бази даних, — і з’ясовується, що фактичного сценарію немає. У кращому разі їм просто «щастило» не натрапляти на критичні кейси.
На практиці для систем із суттєвим стейтом «магічний ролбек» майже ніколи не працює: код можна повернути, а дані — ні. Тому Еріз просуває іншу філософію: «уникати розмов про ролбек, думати лише про roll‑forward».
У цій моделі:
серйозний баг вирішується не поверненням до старої версії, а якомога швидшим хотфіксом — новою, кращою версією;
ланцюжок версій виглядає не як «2 → назад до 1», а як «2 → 3 з виправленням»;
фічетогли слугують «коротким шляхом» для зняття проблемної функції з бою, поки команда готує roll‑forward‑фікс.
Ця філософія напряму пов’язана з прогресивною доставкою: фічетогли дають швидкий важіль миттєво відкотити окрему можливість, а канарні й blue‑green‑схеми — зменшити кількість користувачів, які побачать проблему до того, як вийде виправлення.
Гігієна фічетоглів: сила, яка вимагає прибирання
Є й зворотний бік: фічефлаги легко розмножуються й накопичуються. Еріз прямо визнає, що навіть у команді Octopus Deploy є «застарілі» тогли, які давно мали би бути видалені. У великих продуктах це швидко перетворюється на борг: старі огороджуючі конструкції у коді, складні для розуміння гілки логіки, дублювання сценаріїв.
Щоб тримати цю систему під контролем, у Octopus поверх обраного SDK (вони використовують OpenFeature) побудували власний шар: кожен фічетогл має прив’язку до відповідної команди і «термін придатності». Коли дата минає, ніщо не ламається автоматично, але CI‑процеси можуть сповістити команду: цей тогл давно не мав би існувати, його час переглянути чи видалити.
Ідея не стільки в конкретній реалізації, скільки в принципі: якщо команда всерйоз покладається на фічетогли як фундамент інженерних практик, потрібно впроваджувати й системне «прополювання» — відслідковувати, коли тогл востаннє використовувався, коли був видалений із коду і коли конфігурація безпечно може бути очищена.
З чого почати команді, яка хоче перейти до прогресивної доставки
Еріз радить не чекати «ідеальної архітектури», а зробити перший невеликий крок. Для більшості команд це означає додати один фічетогл для реальної фічі, вивести її в production під контролем, подивитися на поведінку, а потім — вимкнути в разі потреби.
Перший досвід часто змінює ставлення до релізів. Поки немає тоглів, будь‑який баг у production — це набір неприємних питань: чи встигнемо швидко зібрати хотфікс, чи є вікно для деплою, як погодити це з іншими командами. Коли ж є можливість одним кліком забрати фічу з очей користувачів, ситуація з розряду «кризова» переходить у розряд «керована».
Далі питання лише в гігієні та балансі: додавати тогли там, де вони реально дають виграш, і системно їх прибирати після того, як фіча стала «частиною фону».
Висновок
Прогресивна доставка в інтерпретації Роберта Еріза — не про модні терміни чи догму певних інструментів. Це набір практик, які дозволяють командам відправляти зміни в production так само часто, як і раніше, але з меншим ризиком і більшим контролем.
Канарні деплойменти дозволяють вчитися на невеликій частині аудиторії — як це колись робили в Skype з Новою Зеландією. Blue‑green дає змогу перемикати весь трафік на нову версію лише після того, як вона пройшла ізольовану перевірку. А фічетогли забезпечують головне: дрібну одиницю змін, миттєвий відкат окремих фіч і можливість розвести в часі деплой і реліз.
Разом ці три підходи формують практичну відповідь на запитання: як випускати більше змін, не перетворюючи кожен реліз на лотерею. Для інженерів, які щодня живуть у CI/CD‑пайплайнах, це вже не «наступний тренд», а просто нормальна робоча практика, яка дає спати спокійніше вночі.