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

Коротко:

  • Фиче-флаг - переключатель, который включает/выключает код без деплоя.
  • Главная выгода: деплой отделён от релиза, откат - мгновенный.
  • Фиче-флаги позволяют постепенный раскат, A/B-тесты, доступ для бета-групп.
  • Главный риск - флаги, которые забыли убрать (нужен учёт и чистка).

Что это и зачем

Обычно бывает так: написали фичу → задеплоили → она сразу видна всем. Если что-то сломалось, нужен срочный откат и новый деплой. Фиче-флаг разрывает эту связку. Код едет в прод, но спрятан за условием:

if (featureFlags.isEnabled("new-checkout")) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

Теперь включение фичи - это не деплой, а смена настройки флага. Сломалось - выключили за секунды, без релиза. Деплой (код в проде) отделён от релиза (фича видна пользователю).

Что это даёт

  • Мгновенный откат. Проблема в новой фиче - выключили флаг, не дожидаясь хотфикса и деплоя.
  • Постепенный раскат. Включить на 1% пользователей, посмотреть метрики, потом на 10%, 50%, 100%. Канареечный релиз без сложной инфраструктуры.
  • A/B-тесты. Половине показать вариант A, половине B, сравнить - флаг управляет тем, кто что видит. Больше об этом тестировании читайте в отдельной статье.
  • Ранний доступ. Можно включить фичу только для бета-группы или внутренних пользователей.
  • Trunk-based разработка. Незаконченный код можно мёржить в основную ветку выключенным, не держа долгоживущих веток.

Виды флагов

Полезно различать флаги по видам, потому что у них разный срок жизни:

  • Release-флаги - для постепенного выката новой фичи. Они временные, после полного раската убираются.
  • Experiment-флаги - для A/B-тестов. Живут, пока идёт эксперимент.
  • Ops-флаги - переключатели для эксплуатации (например, для отключения тяжёлой функции под нагрузкой). Могут жить долго.
  • Permission-флаги - доступ к фичам для определённых пользователей/тарифов. Долгоживущие по природе.

Смешивать эти флаги в голове - ошибка: release-флаг, который не убрали вовремя, превращается в мусор.

Главный риск: свалка флагов

Самая частая боль - флаги, которые забыли удалить. Код обрастает мёртвыми условиями if flag, которые уже всегда true, ветки old-кода висят годами, и никто не помнит, что можно убрать. Это реальный техдолг и источник багов.

Как не доводить до такого:

  • Заводя release-флаг, сразу ставьте задачу на его удаление после полного раската.
  • Ведите учёт флагов: где, зачем, кто владелец, когда убрать.
  • Регулярно чистите мёртвые флаги, как чистят неиспользуемый код.

Частые вопросы

Нужен ли отдельный сервис для флагов? Для старта хватает простой конфигурации или библиотеки. Готовые системы удобны при росте: UI, таргетинг, аналитика. Из платных - LaunchDarkly и Split (SaaS), из открытых и self-hosted - Unleash и Flagsmith (можно поднять у себя, не отдавая данные наружу). Но суть работает и без них.

Чем флаги отличаются от конфигов? Грань тонкая. Флаги - частный случай конфигурации, заточенный под включение/выключение поведения и таргетинг по пользователям/процентам, часто с динамическим изменением без деплоя.

Не усложняют ли флаги код? Да, каждый флаг - это ветвление. Поэтому временные флаги важно убирать. Польза от управляемых релизов окупает аккуратное обращение.

Как тестировать код с флагами? Проверяйте обе ветки - и включённую, и выключенную. Иначе одна из них может незаметно сломаться.

Главное

Feature flags отделяют деплой от релиза: код едет в прод безопасно, а включается отдельно и постепенно, с мгновенным откатом. Сила - в управляемости релизов, главная опасность - забытые флаги. Заводите их осознанно, с указанием типа, владельца и срока жизни, и регулярно очищайте.

Разбираете такие практики по работе и присматриваетесь к новым командам? Вакансии для разработчиков и DevOps с релокацией собраны на Talanto.

Источники