8.6 Управление релизами и прогрессивная поставка

Обзор и мотивация

Самая полезная идея современного управления релизами и самая простая: отгрузка кода и открытие функции два разных события, и вы должны уметь делать одно без другого. Глава 8.1 (CI/CD и поставка) доводит ваше изменение до состояния «собрано один раз, протестировано и продвинуто как неизменяемый артефакт». Эта глава о том, что происходит дальше: как превратить этот развёрнутый код в живой опыт для реальных пользователей, постепенно, безопасно и с быстрым путём назад. Развёртывание означает установку кода на серверы. Выпуск означает предоставление пользователям доступа к возможности. Когда вы их разделяете, развёртывание становится рутинным и скучным, а выпуск контролируемым обратимым решением.

Для больших команд это разделение меняет эмоциональную температуру отгрузки. Когда десятки сервисов и сотни инженеров меняют производство каждый день, сцепленная модель «развёртывание равно выпуску» означает, что каждое пользовательское изменение рискованное событие «всё сразу». Разделение позволяет сливать незавершённую работу за переключателем, раскатить функцию на один процент трафика, посмотреть на числа и расширить или отступить, не трогая сборку. Прогрессивная поставка общий термин для этого: выпуск изменения всё более широкой аудитории, пока автоматические проверки решают, продолжать ли.

Корпоративные и государственные условия добавляют координацию и доказательства. Платёжная платформа выпускает по многим сервисам, которые должны согласовать схему. Государственное ведомство работает под разрешением на эксплуатацию и формальным контролем изменений, а аудиторам нужны свидетельства того, кто именно подвергся чему и когда. При хорошем исполнении прогрессивная поставка удовлетворяет и желание двигаться быстро, и обязательство доказывать контроль, потому что тот же механизм, ограничивающий радиус поражения, производит проверяемую запись внедрения.

Ключевые принципы

Развёртывание не выпуск. Отгружайте код тёмным, затем включайте его намеренно.
Сначала малый радиус поражения. Открывайте изменение немногим, прежде чем открывать всем.
У каждого выпуска есть задний ход. Если вы не можете откатить за секунды, вы не закончили проектировать выпуск.
Пусть сигналы двигают продвижение. Метрики здоровья и бюджеты ошибок, а не календари или оптимизм, решают, продвигается ли внедрение.
Флаг обязательство, пока не удалён. Каждый переключатель это код, который нужно сопровождать и в итоге удалить.
Сделайте изменение базы данных переживающим оба направления. Внедрения и откаты должны быть безопасны против одной схемы.
Утверждения должны записывать, а не препятствовать. Свидетельство аудита побочный продукт конвейера, а не еженедельное совещание.

Рекомендации

Разделяйте развёртывание и выпуск флагами функций

Переключатель функции, или флаг функции, это переключатель времени выполнения, решающий, активен ли путь кода, без повторного развёртывания. Воспринимайте флаги как типизированный словарь, потому что их сроки жизни различаются. Флаг выпуска скрывает работу в процессе и живёт дни или недели. Операционный флаг (аварийный выключатель) позволяет отключить подсистему под нагрузкой и может жить бесконечно. Флаг эксперимента разделяет трафик для контролируемого теста и живёт на протяжении эксперимента. Флаг разрешения ограничивает возможность по тарифу или роли и фактически постоянен. Дайте каждому флагу владельца, тип, значение по умолчанию и ожидаемую дату удаления. Умолчание должно быть безопасным, чтобы сбой сервиса флагов отказывал закрытым, возвращаясь к заведомо хорошему поведению, а не открытым к непроверенным путям.

Выбирайте шаблон прогрессивной поставки по ярусу сервиса

Подбирайте механизм внедрения под радиус поражения, как глава 8.1 доказывает для стратегий развёртывания. Канареечный выпуск направляет малую долю трафика на новую версию и расширяется, только если здоровье держится. Сине-зелёное развёртывание держит две производственные среды и переключает трафик между ними для мгновенного переключения и мгновенного возврата. Скользящее развёртывание заменяет экземпляры партиями. Кольцевое развёртывание расширяется через именованные аудитории: сначала внутренние пользователи, затем бета-когорта, затем небольшой регион, затем все. Кольца самая полезная рамка для больших организаций, потому что они называют, кто подвергается на каждом шаге, а это именно то, что хотят знать и аудитор, и ответственный за инцидент. Платформы контейнеров и оркестрация (глава 8.3) предоставляют примитивы формирования трафика, делающие эти шаблоны дешёвыми в эксплуатации.

Ограничивайте внедрение проверками здоровья и автоматическим откатом

Определите объективные критерии здоровья до выпуска, а не во время инцидента. Автоматический анализ сравнивает канарейку с базовой линией по доле ошибок, задержке и насыщению и либо продвигает, либо откатывает, не дожидаясь, пока человек заметит. Привяжите продвижение к вашей цели уровня обслуживания и бюджету ошибок из инженерии надёжности сайтов (глава 9.1): когда бюджет здоров, вы выпускаете свободно, а когда потрачен, конвейер отказывается продвигаться, пока сервис не стабилизируется. Автоматический откат важнее всего, потому что убирает нерешительность, превращающую малую регрессию в крупный сбой. Быстрый возврат также ваше самое дешёвое средство контроля инцидентов: откат за секунды сжимает радиус поражения, ещё до того как ваш процесс инцидентов (глава 9.3) полностью раскрутится. Доля неудачных изменений и время восстановления, которые вы так улучшаете, те же сигналы потока и стабильности, что отслеживает ваш конвейер поставки (глава 11.2).

Используйте тёмные запуски и теневой трафик для снижения риска

Некоторые изменения слишком значимы, чтобы впервые встречаться с реальными пользователями при полной экспозиции. Тёмный запуск отгружает функцию выключенной, затем испытывает её внутри или на доле производства, прежде чем кто-либо её увидит. Теневой трафик копирует живые запросы на новый путь кода и отбрасывает ответы, так что вы измеряете реальную нагрузку и корректность при нулевом влиянии на пользователей. Эти приёмы позволяют проверить переписывание или новую зависимость под подлинным трафиком, который ни одна промежуточная среда достоверно не воспроизводит. Сочетайте их с тем же анализом здоровья, что вы используете для канареек.

Проводите контролируемые эксперименты через ту же систему флагов

Флаг эксперимента то место, где релизная инженерия встречается с продуктовым обучением. Разделение A/B-тестирования подаёт варианты сопоставимым когортам и измеряет выбранный результат, питая практику продуктовой аналитики главы 7.4. Повторно используйте одну систему флагов и таргетинга и для безопасных внедрений, и для экспериментов, так что у вас единый след аудита и единый аварийный выключатель, а не два параллельных стека переключателей, расходящихся в том, кто в какой корзине.

Держите базу данных обратно совместимой с расширением и сжатием

Внедрения и откаты остаются безопасными, только если схема терпит и старый, и новый код одновременно, что неизбежно при любом постепенном внедрении. Используйте шаблон расширения и сжатия (параллельного изменения): сначала расширьте, добавив новые столбцы или таблицы в обратно совместимой миграции, затем разверните код, пишущий и в старую, и в новую форму, затем заполните задним числом, затем переведите чтения и только гораздо позже сожмите, удалив старую форму, когда ни один работающий код от неё не зависит. Никогда не объединяйте разрушительную миграцию с развёртыванием, которому она нужна. Эта дисциплина позволяет откатывать код, не имея базы данных, которая уже ушла вперёд, и она напрямую связана с вашей стратегией тестирования (глава 2.4), которая должна покрывать окно смешанных версий.

Сделайте управление изменениями записывающим, а не препятствующим

Согласуйте аудит и поток предварительным утверждением классов изменений. Определите стандартные малорисковые типы изменений, текущие через конвейер автоматически, фиксируя, кто утвердил, какие тесты прошли, какой артефакт развёрнут и какие аудитории были открыты на каждом кольце. Оставляйте человеческую консультативную рецензию для действительно высокорисковых изменений. Традиционный совет контроля изменений, инспектирующий каждое рутинное развёртывание, становится узким местом, толкающим команды к большим, более рискованным партиям, противоположным тому, что он задумывал. В государственном секторе разрешение на эксплуатацию и формальный контроль изменений могут сосуществовать с прогрессивной поставкой, когда инструменты внедрения выдают свидетельства, которых требует рамка контроля, так что запись по кольцам и есть артефакт аудита.

Компромиссы: плюсы и минусы

Шаблон	Плюсы	Минусы	Лучше всего подходит
Канареечный	Основан на данных, малый радиус поражения	Нужны хорошие метрики и объём трафика	Большие пользовательские сервисы
Сине-зелёный	Мгновенное переключение и откат	Удваивает цену среды во время переключения	Критичные сервисы, нуждающиеся в быстром откате
Скользящий	Дёшево, просто, нет дополнительной среды	Медленный откат, живут смешанные версии	Внутренние сервисы без состояния
Кольцевой	Именованные аудитории, ясный след аудита	Медленнее полное внедрение; больше координации	Регулируемые и многосервисные хозяйства
Флаги функций	Разделяют развёртывание и выпуск; мгновенный аварийный выключатель	Долг флагов; растёт матрица тестирования	Команды, безопасно отгружающие незавершённую работу
Релизные поезда	Предсказуемый ритм, лёгкая координация	Сцепляет много изменений; ждёт поезда	Много команд, делящих выпуск
Выпуск по требованию	Малые партии, быстрая обратная связь	Труднее межкомандная координация	Команды непрерывной поставки с высоким доверием

Центральное напряжение между координацией и независимостью. Релизные поезда связывают изменения многих команд в фиксированное расписание, что легко осмыслять, но заставляет готовое изменение ждать и сцепляет несвязанную работу в одно событие. Выпуск по требованию позволяет каждой команде отгружать, когда готова, что быстрее, но требует, чтобы сервисы оставались независимо развёртываемыми и обратно совместимыми. Разрешение обычно в разделении на уровне артефакта и схемы, чтобы команды могли выпускать по требованию, затем использование флагов и колец для координации видимого пользователю момента, когда межсервисная функция действительно включается. Так технический выпуск и продуктовый запуск отдельные решения, и ни одно не блокирует другое.

Вопросы для обсуждения с командой

Когда выпуск идёт не так в два часа ночи, за сколько секунд он разворачивается назад и кто или что нажимает на спуск? Честный ответ показывает, действительно ли вы разделили развёртывание и выпуск или просто добавили флаги поверх сцепленного процесса. Откат, требующий пересборки, миграции базы данных для отмены или вызова человека для решения, не откат, а второй инцидент. Принесите реальный механизм для трёх главных сервисов: флаг или сдвиг трафика, разворачивающий экспозицию, сигнал здоровья, запускающий его автоматически, и гарантию схемы, делающую возврат безопасным. Для большого хозяйства это определяет ваш реальный радиус поражения, потому что быстрый автоматический возврат удерживает регрессию от превращения в сбой. Если ответ измеряется совещаниями, а не секундами, это первое, что нужно исправить.
Какова ваша политика вывода флагов и сколько долга флагов вы несёте прямо сейчас? Каждый флаг функции это развилка в вашем коде, умножающая число состояний, о которых нужно рассуждать и которые нужно тестировать, а флаг, пережививший свою цель, чистое обязательство. Решите правило сейчас: каждый флаг выпуска получает владельца и дату истечения, устаревшие флаги всплывают на панели, а их удаление плановая работа, а не когда-нибудь уборка. Принесите подсчёт живых флагов, их возраст и сколько прошло намеченную дату удаления. В большой кодовой базе неуправляемые флаги становятся постоянной условной сложностью, которую никто не смеет удалить, а механизм безопасности превращается в источник ошибок. Терпимость команды к этому числу на деле утверждение о том, насколько серьёзно она относится к операционной гигиене.
Делает ли ваш процесс утверждения изменений выпуски безопаснее или просто медленнее? Многие организации ведут консультативный совет по изменениям, рецензирующий каждое развёртывание, и неудобный вопрос в том, остановил ли он когда-нибудь действительно плохое изменение или просто добавил задержку. Принесите данные: медианную задержку утверждения, долю неудачных изменений для рецензированных советом против предварительно утверждённых изменений и как часто рецензия собирает мелкие изменения в более крупные, более рискованные. Цель оставить человеческую рецензию для действительно высокорисковых изменений, позволяя стандартным изменениям течь через конвейер с автоматическим захватом свидетельств. Для регулируемых и государственных контекстов проверьте, что инструменты внедрения производят запись аудита, нужную рамке контроля, так что контроль становится побочным продуктом отгрузки, а не барьером перед ней. Если рецензия добавляет задержку, не снижая отказов, это театр в костюме соответствия.
На каких объективных сигналах здоровья вы готовы позволить действовать машине и есть ли у каждого сервиса верхнего яруса метрики достаточно хорошие для ограничения? Автоматический канареечный анализ и ограничение по бюджету ошибок работают, только если доля ошибок, задержка и насыщение измеряются достаточно чисто, чтобы доверять продвижению или откату без человека в контуре, а многие команды обнаруживают во время инцидента, что их сигналы слишком шумны или скудны для решения. Для большого хозяйства это определяет, какая доля вашего объёма выпусков может течь безопасно без ручной няньки, а это разница между платформой, которая масштабируется, и той, которой нужен человек, следящий за каждым внедрением. Принесите настоящие панели для трёх самых критичных сервисов: метрики, по которым вы ограничиваете, объём трафика, делающий канарейку статистически значимой, и долю ложных срабатываний вашего автоматического анализа. В регулируемой и государственной среде те же сигналы питают проверяемую запись, поэтому плохая наблюдаемость и пробел надёжности, и пробел соответствия, а финансирование качества метрик должно быть названной строкой плана, а не предполагаемой возможностью.
Переживают ли ваши изменения схемы откат и как вы доказываете, что окно смешанных версий безопасно, до того как отгрузите? Прогрессивная поставка обещает быстрый задний ход, но разрушительная миграция, сцепленная с функцией, тихо аннулирует это обещание, потому что откат кода оставляет его направленным на базу данных, которая уже ушла вперёд. Для большой организации, где многие сервисы делят схему, риск накапливается: шаг сжатия одной команды может оставить без отката другую, поэтому дисциплина расширения и сжатия должна быть общим стандартом, а не локальной привычкой. Принесите ваш сценарий миграций и свидетельства, что ему следуют: как вы отделяете расширение от сжатия, тестируются ли двойная запись и заполнение задним числом под нагрузкой и как ваш набор тестов задействует старый код против новой схемы и новый код против старой. Для корпоративных и государственных хозяйств с долгоживущими данными и формальным контролем изменений необратимая миграция не просто риск сбоя, а экспозиция целостности данных и аудита, которую не спасёт плановое окно обслуживания.
Когда межсервисная функция охватывает команды, отгружающие с разной скоростью, кто владеет моментом её включения и как вы координируете, не сцепляя их развёртывания? Весь смысл разделения развёртывания и выпуска в том, что каждая команда может отгружать свой артефакт независимо, пока единый флаг управляет видимым пользователю запуском, но это держится, только если кто-то владеет решением о запуске и таргетингом флага через границы сервисов. Для большой команды режим отказа это фактический релизный поезд, которого никто не выбирал: один медленный сервис заставляет ждать все остальные команды, или нескоординированное переключение флага открывает наполовину подключённую функцию. Принесите карту зависимостей для вашего следующего многосервисного запуска, владельца флага запуска и гарантии обратной совместимости, позволяющие каждому сервису развёртываться по своим часам. В корпоративных и государственных программах с формальными утверждениями запуска назовите, кто подписывает межсервисное включение и какие свидетельства видит, чтобы координированный запуск был намеренным записанным решением, а не случайностью того, кто слил последним.

Взгляд по секторам

Стартап. Разделение развёртывания и выпуска стоит делать даже с тремя инженерами, но держите это дешёвым. Оборачивайте новую работу во флаг выпуска, по умолчанию выключенный, отгружайте в ствол и включайте функции для себя раньше клиентов, так что незавершённое изменение никогда не блокирует развёртывание. Пропустите тяжёлые платформы канареечного анализа, которые вы не можете обслужить: размещённый сервис флагов и жёсткий аварийный выключатель покупают большую часть безопасности, а один человек, владеющий еженедельным ритуалом уборки флагов, не даёт долгу проглотить вашу скорость.

Малый бизнес. Без релиз-инженера и при ограниченном бюджете опирайтесь на любую прогрессивную поставку, которую уже даёт ваша платформа, а не стройте систему внедрения. Управляемый хостинг, SaaS флагов функций или встроенное поэтапное внедрение вашего фреймворка обычно покрывает нужный вам малый радиус поражения. Воспринимайте задний ход как то, что нужно сделать правильно: изменение, которое можно выключить за секунды, значит гораздо больше, чем сложный автоматический анализ, который вам некогда настраивать.

Крупная организация. Проблема согласованность по многим командам и сервисам: общий словарь флагов с владельцами, типами и истечением, стандартное кольцевое внедрение и ограничение по бюджету ошибок, применяемые везде одинаково, чтобы группы перестали изобретать соперничающие стеки переключателей. Управляйте долгом флагов как метрикой всего хозяйства, стандартизируйте миграции расширения и сжатия, чтобы изменение схемы одной команды никогда не оставляло без отката другую, и делайте проверяемую запись внедрения побочным продуктом, который каждый сервис испускает в одной форме. Предварительно утверждайте стандартные изменения и оставляйте человеческую рецензию для действительно высокорисковых, чтобы контроль масштабировался без совета на критическом пути.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность формируют каждый выпуск. Сделайте инструменты внедрения источником свидетельств аудита, так что каждое расширение кольца записывает утверждающий орган, прошедшие тесты, хеш артефакта и точную открытую популяцию, и разрешение на эксплуатацию сосуществует с прогрессивной поставкой, а не борется с ней. Предпочитайте сине-зелёные или кольцевые шаблоны, чьи именованные аудитории могут прочесть и аудитор, и ответственный за инцидент, проверяйте значимые изменения теневым трафиком на живых случаях до того, как пострадает хоть один гражданин, и держите проверяемую запись как артефакт, принимаемый рамкой контроля вместо планового окна «всё разом».

Примеры

Стартап. SaaS-компания из десяти человек отгружает в ствол много раз в день и оборачивает каждую новую возможность во флаг выпуска, по умолчанию выключенный. Рискованная новая интеграция выставления счетов запускается тёмной: они неделю гоняют против неё теневой трафик, наблюдая, как она обрабатывает реальные формы запросов без влияния на клиентов, затем раскатывают её кольцо за кольцом, начиная со своих учётных записей и горстки дружественных бета-клиентов. Когда на кольце в пять процентов доля ошибок подскакивает, автоматическая проверка выключает флаг за секунды, а они спокойно отлаживают в понедельник. Один инженер владеет еженедельным ритуалом уборки флагов, так что переключатели никогда не накапливаются.

Крупная организация. Глобальная платёжная компания координирует изменение, охватывающее шесть сервисов и общую схему. Каждая команда развёртывает свой артефакт независимо и обратно совместимо с помощью расширения и сжатия, так что новые столбцы существуют и пишутся дважды задолго до того, как какой-либо пользователь видит функцию. Видимый пользователям запуск единый флаг эксперимента, раскатываемый кольцами, привязанными к здоровью бюджета ошибок: внутренние, затем одна небольшая страна, затем расширяющийся процент, с автоматическим канареечным анализом, продвигающим или откатывающим на каждом шаге. Сервис управления флагами принуждает владельцев, типы и истечение по хозяйству, а предварительно утверждённые стандартные изменения текут без совета, тогда как только шаг сжатия схемы получает человеческую рецензию. Каждый переход кольца журналируется, так что след аудита пишется сам.

Государственный сектор. Национальное ведомство по пособиям работает под разрешением на эксплуатацию и формальным контролем изменений. Вместо того чтобы воспринимать прогрессивную поставку как риск соответствия, оно делает инструменты внедрения источником свидетельств аудита: каждое расширение кольца записывает утверждающий орган, прошедшие тесты, хеш артефакта и точную открытую популяцию. Новый расчёт права на пособие запускается тёмным и проверяется теневым трафиком на живых случаях, затем раскатывается регион за регионом за флагом с сине-зелёным переключением для мгновенного возврата. Стандартные изменения предварительно классифицированы, так что рутинная работа не стоит в очереди за советом, тогда как высокорисковые политические изменения по-прежнему получают формальную рецензию. Проверяемая запись внедрения удовлетворяет рамке контроля полнее, чем старый квартальный выпуск «всё разом» когда-либо.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от прогрессивной поставки определяется избегнутыми инцидентами и сниженной их серьёзностью. Изменение, достигшее одного процента пользователей и автоматически откатившееся, стоит ошибки округления, тогда как тот же дефект при полной экспозиции может означать часы сбоя, аварийного реагирования и репутационного ущерба. Разделение развёртывания и выпуска также превращает сам выпуск из планового стрессового события в рутинное, что снижает налог на координацию, растущий нелинейно с размером команды. Отделение решения о запуске от развёртывания позволяет продукту и инженерии двигаться по своим часам, так что маркетинговая дата никогда не вынуждает рискованную заморозку кода.

Совокупная стоимость владения реальна, но скромна на фоне этого выигрыша. Вы вкладываетесь в платформу флагов, инструменты канареечного анализа, метрики здоровья достаточно хорошие для ограничения и дисциплину обратно совместимых изменений схемы. Постоянная цена это гигиена флагов и большая матрица тестирования, которую создают флаги, поэтому неуправляемое хозяйство флагов главный способ, которым эта практика становится дорогой. Цена непринятия платится радиусом поражения: каждый выпуск «всё или ничего», откаты медленные, а одно плохое развёртывание может обрушить всех разом. Для регулируемых организаций дивиденд соответствия решающий, потому что тот же механизм, ограничивающий экспозицию, производит и проверяемые свидетельства, которые иначе собирали бы вручную.

Антипаттерны и ловушки

Развёртывание равно выпуску. Их сцепление делает каждое пользовательское изменение рискованным событием «всё разом» без заднего хода.
Долг флагов. Переключатели, пережившие свою цель, становятся постоянной условной сложностью, которую никто не смеет удалить.
Флаги, отказывающие открытыми. Сбой сервиса флагов, по умолчанию переключающий на новый непроверенный путь, превращает малый сбой в аварию.
Откат, которому нужна отмена схемы. Разрушительная миграция, отгруженная вместе с функцией, оставляет вас неспособными безопасно откатить код.
Ручное продвижение по ощущениям. Продвижение внедрения, потому что «выглядит нормально», а не по определённым критериям здоровья и бюджетам ошибок.
Внедрение без плана отката. Проектирование того, как включить функцию, без проектирования того, как её выключить.
Штамповка в совете по изменениям. Рецензия, никогда ничего не отклоняющая, добавляет задержку без безопасности и толкает команды к большим партиям.
Флаги экспериментов и безопасности в разных системах. Два стека переключателей, расходящихся в том, кто в какой корзине, удваивают поверхность аудита.

Модель зрелости

Уровень 1, Начальный: Развёртывание и выпуск одно событие. Изменения уходят все разом, откат означает ручное повторное развёртывание старой сборки, а миграции схемы разрушительны и сцеплены с функциями. Любая постепенная экспозиция стихийна, реактивна и недокументирована.
Уровень 2, Развитие: Флаги функций есть у некоторых команд и скрывают незавершённую работу, но у них нет владельцев, типов и истечения, и долг копится. Канареечное или сине-зелёное используется для нескольких критичных сервисов, применяется непоследовательно от команды к команде. Откат скриптован, но запускается человеком, а изменения схемы лишь иногда обратно совместимы.
Уровень 3, Стандартизация: Развёртывание и выпуск разделены по умолчанию по организации. Флаги типизированы, имеют владельцев и истекают, с безопасными умолчаниями, следуя документированному и принуждаемому стандарту. Прогрессивная поставка с кольцевым внедрением и автоматическим канареечным анализом норма, миграции расширения и сжатия обязательны, а стандартные изменения текут через конвейер с автоматическим захватом свидетельств.
Уровень 4, Управление: Процесс выпуска измеряется и контролируется данными. Доля неудачных изменений, среднее время восстановления, задержка отката, возраст и число флагов и доля ложных срабатываний канарейки отслеживаются относительно базовых значений и бюджетов ошибок, а внедрения ограничиваются этими SLO (глава 9.1), так что продвижение и откат действуют автоматически по определённым сигналам здоровья. Долг флагов сообщается как метрика всего хозяйства и выводится по расписанию, а отклонения от стандарта внедрения всплывают на панели, а не в разборе.
Уровень 5, Оркестрация: Прогрессивная поставка непрерывно улучшается и интегрирована по организации. Тёмные запуски и теневой трафик рутинно снижают риск крупных изменений, эксперименты и безопасные внедрения делят одну систему флагов и след аудита, а политика выпуска адаптируется к состоянию бюджета ошибок в реальном времени. Проверяемая запись внедрения удовлетворяет контроль изменений (глава 9.3) как побочный продукт, а организация настраивает свои кольца, барьеры и пороги по свидетельствам по мере сдвигов хозяйства и картины рисков.

Идеи для обсуждения

Для вашего самого критичного сервиса где правильная граница между автоматическим откатом по здоровью и человеческим решением и какому сигналу вы доверились бы достаточно, чтобы позволить машине действовать одной?
Следует ли флагам экспериментов и флагам выпуска делить одну платформу и один аварийный выключатель или их объединение создаёт больше риска, чем убирает?
Как выбирать между релизным поездом и выпуском по требованию, когда функция охватывает несколько команд, отгружающих с разной скоростью?
Каков честный период полураспада флага выпуска в вашей кодовой базе и что сделало бы удаление столь же рутинным, как создание?
Как состояние бюджета ошибок должно менять, кому позволено выпускать, и кто владеет решением заморозить выпуски, когда бюджет потрачен?
В вашем регулируемом контексте какие конкретные свидетельства должно испускать внедрение, чтобы рамка контроля приняла прогрессивную поставку вместо планового окна выпуска?

Главные выводы

Разделяйте развёртывание и выпуск. Отгрузка кода и открытие функции разные решения, и флаги их разделяют.
Внедряйте прогрессивно. Канареечные, сине-зелёные, скользящие и кольцевые шаблоны ограничивают радиус поражения; выбирайте по ярусу сервиса по риску.
Ограничивайте по здоровью и бюджетам ошибок. Пусть определённые сигналы и SLO (глава 9.1) двигают автоматическое продвижение и откат, а не календари или оптимизм.
Сначала проектируйте задний ход. Быстрый безопасный откат сжимает радиус поражения до того, как ваш процесс инцидентов (глава 9.3) полностью включится.
Типизируйте, закрепляйте за владельцем и устаревайте каждый флаг. У флагов выпуска, эксплуатации, экспериментов и разрешений разные сроки жизни; неуправляемые флаги становятся долгом.
Делайте изменения схемы обратно совместимыми. Используйте расширение и сжатие, чтобы и внедрение, и откат оставались безопасными в окне смешанных версий (глава 2.4).
Пусть утверждения записывают, а не препятствуют. Предварительно утверждайте стандартные изменения и оставляйте человеческую рецензию для высокого риска, так что запись внедрения и есть свидетельство аудита.

Источники и дополнительное чтение

Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay on martinfowler.com).
Danilo Sato, “Canary Release” and Martin Fowler, “BlueGreenDeployment” (essays on martinfowler.com).
Sam Newman, Building Microservices: Designing Fine-Grained Systems (expand-and-contract and independent deployability).
Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design (parallel-change schema migrations).
Ron Kohavi, Diane Tang, and Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing.
James Governor, “Progressive Delivery” (RedMonk, the coining of the term).