Feature-флаги отвязывают деплой от релиза

«Я не могу мёржить ежедневно — моя фича не закончена. Я не могу положить половину flow checkout-а на trunk.» Это возражение топит большинство внедрений trunk-based, и оно держится на скрытом допущении: что положить код в прод значит показать его пользователям. Разделите эти два — и возражение растворяется. Полузаконченный flow checkout-а уезжает в прод сегодня, прогоняется через CI, лежит там полностью интегрированный — и ни один пользователь не может до него добраться, потому что он за выключенным флагом. Вы развернули код. Вы не выпустили фичу.

Деплой и релиз — разные события

Связывание «деплоя» и «релиза» в один акт — вот что вынуждает к долгоживущим веткам: если выкатить код — то же, что показать фичу, то незавершённая работа должна оставаться вне trunk, пока не готова. Feature-флаги разбивают эту связку. Развёртывание — это перенос кода на прод-серверы. Релиз — это сделать фичу достижимой пользователями. Флаг — рантайм-переключатель между ними: оберните новый путь в условие, читающее флаг, выкатите его выключенным — и код развёрнут, интегрирован и протестирован, но тёмный: присутствует и недостижим.

Именно это делает ежедневную интеграцию совместимой с многонедельными фичами. Работа мёржится в trunk каждый день как малые зелёные коммиты, каждый спрятан за выключенным флагом, так что вы никогда не накапливаете разрыв (урок 1) и никогда не нуждаетесь в долгоживущей ветке (урок 2). Когда фича завершена, вы ничего не развёртываете — вы переключаете флаг. Релиз перестаёт быть рискованным большим пушем и становится изменением конфигурации, которое можно сделать в 10 утра во вторник, пока автор смотрит на дашборды.

Dark launch и постепенная экспозиция

Когда релиз стал рантайм-решением, вы получаете возможности, которых деплой дать не может. Dark launching означает прогонять новый путь кода в проде до показа его результатов пользователям — например, слать реальный трафик на новый сервис рекомендаций, сравнивать его вывод со старым и измерять задержку, но выбрасывать новый вывод. Вы нагрузочно тестируете и валидируете против реальности прода с нулевым видимым для пользователя риском. Затем вы постепенно экспонируете: включаете фичу для внутренних пользователей, потом 1%, потом 5%, 25%, 100%, наблюдая за частотой ошибок и задержкой на каждом шаге. Это canary через флаг — blast radius растёт только по мере роста уверенности.

Тот же переключатель — ваш самый быстрый инструмент восстановления. Если разогнанная фича ведёт себя плохо на 5%, вы выключаете флаг — kill switch — и каждый пользователь возвращается на старый путь за секунды, без отката-деплоя, без revert-PR, без ожидания CI. Отвязывание деплоя от релиза превращает «мы выкатили баг, начинаем инцидент» в «мы его выключили, теперь спокойно дебажим».

Не каждый флаг — один и тот же зверь

Одно слово «флаг» прячет четыре очень разные вещи, и их смешение — это как гниют системы флагов. Release-флаг — временные леса: он существует, чтобы прятать незавершённую работу и разгонять выкатку, и должен быть удалён, как только фича на 100%. Ops-флаг (kill switch) призван жить вечно, чтобы вы могли сбрасывать нагрузку или отключать сбоящую подсистему во время инцидента. Experiment-флаг живёт один A/B-цикл. Permission-флаг постоянен, потому что кодирует продуктовое правило (эта фича — для планов Pro). Опасная категория — release-флаг, потому что он выглядит постоянным, если о нём забыть — а забытый release-флаг — это проблема flag debt из следующего урока.