Feature Flags

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

На ранних этапах CI/CD «задеплоить» и «зарелизить» звучат как синонимы: код приехал на продакшен, пользователи увидели функционал, всё. Рано или поздно случается коллизия, которая разводит эти понятия. Команда доделала фичу, задеплоила, а маркетинг просит придержать до вторника — у них PR-кампания. Получается заведённая бомба: код на проде, показывать его рано, и если кто-то заметит неанонсированную функциональность, будет скандал.

Feature flags разделяют деплой и релиз на две независимые операции. Деплой — код едет на серверы. Релиз — пользователи получают доступ к функционалу. Между ними может пройти минута, день или неделя, и разработчикам не нужна отдельная ветка, заморозка мержа или согласование тайминга с десятком команд.

Как устроен feature flag

В минимальном виде feature flag — это условие в коде:

if (featureEnabled("new-checkout")) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Значение featureEnabled живёт не в коде, а во внешней системе — конфиг-файле, переменной окружения или специализированном сервисе. Код с обеими ветками деплоится один раз, флаг включается и выключается без передеплоя.

Pete Hodgson в статье на сайте Martin Fowler выделяет несколько категорий флагов. Разделение полезное: разные категории требуют разного управления.

Release toggles прячут незавершённый или неанонсированный функционал. Живут дни или недели, убираются после полного раскатывания фичи. Самый частый тип.

Experiment toggles управляют A/B-тестами. Живут столько, сколько идёт эксперимент (обычно недели), привязаны к конкретным когортам пользователей.

Ops toggles дают эксплуатации возможность вырубить тяжёлую функциональность под нагрузкой. Могут жить долго, работают как circuit breaker.

Permission toggles разграничивают доступ к функциям между категориями пользователей (free vs premium, бета-тестеры). Живут столько, сколько существует разделение.

Progressive rollout

Один из главных козырей feature flags — постепенное раскатывание. Вместо включения для всех 100% пользователей с молитвой о стабильности процесс идёт ступеньками: 1%, метрики (error rate, latency, конверсия), 5%, снова метрики, 10%, 50%, 100%.

Unleash умеет стратегии постепенного раскатывания из коробки: задаётся процент пользователей, выбирается стратегия (gradual rollout, user ID, IP), система направляет трафик по правилам. В связке с Grafana и Prometheus метрики видны в реальном времени, и решение об увеличении процента или откате принимается на их основе. У GrowthBook статистический анализ A/B-экспериментов встроен в сам инструмент — на выходе не просто графики, а оценка значимости результатов.

Постепенное раскатывание перерисовывает картину рисков. Деплой перестаёт быть бинарным «всё или ничего» и превращается в управляемый процесс с мгновенным откатом. Откат feature flag — переключатель в интерфейсе или API-запрос на пару секунд. Откат деплоя — пайплайн на минуты или часы.

Инструменты

Рынок feature flag-платформ зрелый. Для команд, которым важен контроль над данными и инфраструктурой, лучший выбор — open-source решения с self-hosting.

Unleash (GitHub). Главная рекомендация. Open-source, self-hosted, данные остаются на собственных серверах. Targeting по пользователям и сегментам, стратегии постепенного раскатывания, A/B-тесты, audit log. SDK для 15+ языков. Интеграция с Grafana и Prometheus через встроенные метрики. Есть платная managed-версия Unleash Edge для тех, кому неохота поднимать инфраструктуру самостоятельно.

Flagsmith (GitHub). Open-source, self-hosted. Помимо boolean-флагов умеет в remote config — значения строк, чисел, JSON. Подходит, когда хочется держать feature flags и конфигурацию в одном месте. Есть REST API и вебхуки для интеграции с Grafana OnCall для алертинга.

GrowthBook (GitHub). Open-source платформа, объединяющая feature flags и A/B-эксперименты. Встроенный статистический движок анализирует результаты и показывает значимость. Подключается к data warehouse (ClickHouse, Postgres, BigQuery) для анализа метрик.

OpenFeature (GitHub). Открытый стандарт от CNCF — единый API для работы с feature flags. Позволяет переключаться между провайдерами (Flagsmith, Unleash, GrowthBook) без переписывания кода. SDK для Go, Java, .NET, JavaScript, Python и других языков. Если архитектура закладывается на вырост — начинайте с OpenFeature API и подключайте любого провайдера.

LaunchDarkly держится в лидерах enterprise-рынка с самым широким набором интеграций и SDK для 25+ языков. Это SaaS с серверами за пределами РФ и ценником от $10 в месяц за разработчика — для команд с требованиями к локализации данных вариант сомнительный.

Маленьким командам годится и самодельное решение: JSON-файл в S3-совместимом хранилище или переменная окружения. Главное — вытащить решение о включении/выключении из кода в конфигурацию. Инфраструктуру вокруг можно растить по мере потребностей.

Техдолг от флагов

Pete Hodgson называет главную проблему feature flags «flag debt». Стейловые флаги засоряют кодовую базу условиями и мёртвым кодом. Флаг создан полгода назад под релиз фичи, фича давно работает для всех, а условие в коде осталось, ветка со старой логикой — тоже, и никто не возьмётся удалить, потому что автор уволился в прошлом квартале.

200 feature flags в продакшене, из них 150 стейловые — это 150 лишних точек ветвления. Код становится труднее читать, рефакторинг буксует, появляется комбинаторный взрыв состояний, который не покрывается тестами.

Практики против flag debt:

Expiration date. При создании флага указывается дата, после которой его пора удалять. Дата прошла, флаг живой — CI кидает warning или блокирует сборку.

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

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

Правило при создании. Pete Hodgson советует при каждом создании release toggle сразу заводить в бэклог задачу на его удаление. Флаг и задача на его удаление — пара, разрывать которую нельзя.

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

Как устроен feature flag

Progressive rollout

Инструменты

Техдолг от флагов

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