Feature flags в проде без лишнего риска

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-флаг, сразу ставьте задачу на его удаление после полного раската.
• Ведите учёт флагов: где, зачем, кто владелец, когда убрать.
• Регулярно чистите мёртвые флаги, как чистят неиспользуемый код.

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

Главное

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

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

Источники

• Feature Toggles (aka Feature Flags) — Martin Fowler / Pete Hodgson