Флаги фич: как инкрементальная доставка снижает риски релизов
Что такое feature flags, почему команды, которые их используют, релизят быстрее и ломают меньше, и что нужно знать собственнику до того, как их внедрять.
Есть паттерн, который я вижу регулярно в растущих продуктовых компаниях. Команда научилась шипать часто, но каждый релиз по-прежнему остаётся тревожным событием. Все знают, что плохой деплой в пятницу после обеда может испортить выходные. Поэтому релизы накапливаются, батчи растут, и в какой-то момент компания снова шипает раз в месяц и называет это «стабильностью».
Feature flags - одно из самых чистых решений этой проблемы. И одновременно их часто неправильно понимают те, кто не работал с ними - или внедрял только наполовину, а потом обвинял в сложности, которую они не создавали.
Что такое feature flag
Feature flag - это условие в коде, которое оборачивает функциональность: «если этот флаг включён, показывай новое поведение; если выключен - старое». Флагом управляют снаружи кодовой базы - обычно через сервис конфигурации или простую запись в базе - без повторного деплоя.
Это значит, что можно задеплоить код, содержащий новую функцию, оставить флаг выключенным и включить его позже - для всех пользователей, для процента, для конкретного аккаунта, только для внутренних тестировщиков. Деплой и релиз становятся двумя отдельными событиями.
Почему это важно операционно
Когда деплой и релиз разделены, меняется несколько вещей:
Откат становится дешёвым. Если что-то пошло не так после включения флага - вы его выключаете. Никаких хотфиксов, откатных деплоев, инцидентов в 2 ночи. Код по-прежнему там, функция просто невидима.
Постепенный роллаут становится возможным. Можно включить функцию для 1% пользователей, наблюдать за ошибками и тикетами поддержки, потом поднять до 10%, 50%, 100%. Проблемы всплывают на том масштабе, где с ними ещё легко справиться.
Тестирование в продакшне становится безопасным. Внутренние команды могут пользоваться функцией неделями до того, как её увидит любой клиент. Обратная связь реальная - тестовые окружения врут в тех местах, где продакшн не врёт.
Цена вопроса
Feature flags - не бесплатный инструмент. Основные издержки:
- Долг флагов. Флаги, которые не убирают, накапливаются. Через год в коде десятки условий, про часть которых никто не уверен, нужны ли они ещё. Это требует дисциплины: у каждого флага должен быть тикет на удаление после полного роллаута.
- Сложность тестирования. При N флагах теоретически существует 2^N комбинаций. На практике большинство комбинаций нереалистичны, но нужно думать о тех, которые реальны.
- Операционная зависимость. Если сервис, который раздаёт значения флагов, падает, нужно определить fallback. Обычно это означает «безопасные значения по умолчанию» прямо в коде.
Что нужно договориться на уровне управления
С управленческой точки зрения ключевые вещи, которые нужно согласовать до внедрения системы флагов:
- Кто может создавать и менять флаги - и в каких окружениях.
- Каков жизненный цикл флага: создан, активен, полный роллаут, удалён. Каждый флаг проходит этот путь и удаляется в конце.
- Как именуются флаги, чтобы через полгода любой мог понять, что делает флаг, по его названию.
- Что означает «процентный роллаут» для вашей базы - это по пользователю, по аккаунту, по сессии?
Механика достаточно простая - любая приличная инженерная команда построит базовую версию за несколько дней. Коммерческие решения (LaunchDarkly, Unleash, Flagsmith) добавляют аудит-логи, правила таргетинга и интеграции с метриками - это окупается, когда активных флагов больше десятка.
Более широкий контекст
Feature flags - симптом здоровой культуры доставки, где «готово» означает «в руках пользователей, под мониторингом, с возможностью быстро откатить». Это изменение культуры больше, чем любой конкретный инструмент. Но инструмент помогает поддерживать эту культуру под давлением.