Флаги фич как инструмент управления рисками при выпуске
Как feature flags меняют логику выпуска релизов и почему это управленческий вопрос, а не только технический.
Когда я разговариваю с собственниками о проблемах с выпуском новых функций, разговор почти всегда упирается в один и тот же паттерн. Большой релиз, долгое тестирование, напряжённый запуск, а потом либо всё работает - либо срочно откатываем. Цикл длинный, риски концентрированные, команда выжата.
Флаги фич - один из инструментов, который позволяет сломать этот паттерн. Но чтобы они работали, нужно понимать, что именно они меняют.
Что такое флаг фичи
Флаг фичи - это переключатель в коде, который позволяет включить или выключить определённую функциональность без нового деплоя. Код уже в продакшне, но фича выключена. Когда нужно - её включают, нужно откатить - выключают.
На первый взгляд это звучит как простой технический трюк. Но за ним стоит принципиально другой способ думать о рисках выпуска.
В классической схеме деплой и включение функции - одно событие. Что-то пошло не так - надо откатить весь деплой, а это сложно и долго. В схеме с флагами это два разных события. Деплой можно делать часто и без страха. Включение фичи - отдельное решение, которое можно принять в любой момент и отменить за секунды.
Что это меняет для бизнеса
Первое - скорость обратной связи. Новую функцию можно показать сначала 1% пользователей, посмотреть на метрики, потом расширить или свернуть. Это не A/B-тест в академическом смысле, это просто постепенное раскрытие с возможностью остановиться.
Второе - управление инцидентами. Если новая функция вызвала проблему, её можно выключить немедленно, не дожидаясь отката и не затрагивая остальную систему. Для операционного бизнеса, где каждая минута простоя стоит денег, это существенно.
Третье - разделение деплоя и решения о запуске. Технический деплой можно сделать ночью в тихое время. Решение о включении фичи принимает бизнес тогда, когда нужно. Это разные ритмы и разные ответственные.
Где это начинает усложняться
Флаги фич - не бесплатный инструмент с точки зрения управления.
Флаги накапливаются. Каждый флаг - это ветвление в коде. Если ими не управлять, через год в системе будет несколько десятков флагов, часть из которых уже не нужна, но никто не решается убрать. Это технический долг в чистом виде.
Флаги требуют дисциплины именования и документирования. Флаг "new_checkout_flow" через полгода никто не помнит - включён ли он по умолчанию, для кого, и можно ли его убрать.
Флаги взаимодействуют. Если несколько флагов включены одновременно, их комбинации могут давать неожиданные результаты. Это нужно отслеживать.
Хорошие команды заводят реестр флагов с датами истечения и владельцами. Плохие - просто добавляют новые.
Вопросы для практики
Если в вашей компании идёт разговор о снижении рисков при выпусках, я бы проверил:
- Как сейчас выглядит типичный процесс от готовности кода до включения у пользователей?
- Что происходит, когда после деплоя обнаруживается проблема - сколько это занимает и кто принимает решение?
- Есть ли механизм постепенного раскрытия новых функций, или всё включается разом для всех?
- Если бы завтра надо было срочно выключить новую функцию - как это делается?
Флаги фич - один из ответов на эти вопросы, но не единственный. Важнее сам разговор о том, как компания управляет риском изменений в продукте.