Что такое Feature Flags?
Feature flags (также называемые feature toggles) — это условные конструкции в коде, управляющие активностью фичи. Они отделяют деплой кода от выпуска фичи — вы можете задеплоить код в продакшен со скрытыми фичами, затем включать их постепенно.
Для QA-инженеров feature flags добавляют сложность тестирования, но дают мощные возможности: безопасное тестирование фич в продакшене, управление A/B-экспериментами и мгновенный откат проблемных фич без передеплоя.
Типы Feature Flags
| Тип | Время жизни | Назначение | Фокус тестирования |
|---|---|---|---|
| Release flags | Короткое (дни-недели) | Скрыть незавершённые фичи | Оба состояния on/off |
| Experiment flags | Среднее (недели-месяцы) | A/B-тестирование, метрики | Поведение вариантов |
| Ops flags | Долгоживущие | Circuit breakers, kill switches | Режимы отказа |
| Permission flags | Долгоживущие | Фичи по пользователям (premium, beta) | Поведение по группам |
Стратегия тестирования Feature Flags
Комбинаторная проблема
При N независимых флагах существует 2^N комбинаций. При 10 флагах — 1024 комбинации.
Прагматичный подход:
- Тестируйте каждый флаг независимо в обоих состояниях (2N тестов)
- Определите зависимые флаги, взаимодействующие друг с другом, и тестируйте их комбинации
- Тестируйте переходы — переключение флага во время сессии пользователя
- Тестируйте состояние по умолчанию — что видят пользователи при недоступности сервиса флагов
Пример тестовой матрицы
Для feature flag “new-checkout”:
| Сценарий | Состояние | Что тестировать |
|---|---|---|
| Feature off (default) | OFF | Legacy checkout работает корректно |
| Feature on | ON | Новый checkout работает корректно |
| Переход: off → on | OFF → ON | Переключение mid-session не портит данные корзины |
| Переход: on → off | ON → OFF | Откат не теряет данные пользователя |
| Сервис флагов недоступен | FALLBACK | Приложение корректно деградирует к default |
Инструменты Feature Flags
| Инструмент | Тип | Ключевая особенность |
|---|---|---|
| LaunchDarkly | SaaS | Enterprise, обновления в реальном времени |
| Split.io | SaaS | Встроенная экспериментация |
| Unleash | Open source | Self-hosted, расширяемый |
| Flagsmith | Open source | API-first, удалённая конфигурация |
| ConfigCat | SaaS | Простой, доступный |
Упражнение: Спроектируйте стратегию тестирования флагов
Ваша команда запускает новый движок рекомендаций за feature flag с тремя вариантами: “off” (legacy), “basic” и “advanced” (ML). Прогрессивный rollout: 1% → 10% → 50% → 100%.
Решение
Фаза 1: До rollout
Функциональные тесты по вариантам:
- OFF: Legacy-страница продукта, без секции рекомендаций
- BASIC: Секция рекомендаций показывает связанные продукты по категории
- ADVANCED: ML-рекомендации, персонализированные по пользователю
Тесты переходов:
- OFF → BASIC: рекомендации появляются без проблем перезагрузки
- BASIC → ADVANCED: ML-рекомендации заменяют базовые
- ADVANCED → OFF: секция чисто исчезает
Фаза 2: Прогрессивный Rollout
При 1%: Smoke-тесты в продакшене, мониторинг error rate При 10%: Сравнение метрик между вариантами (A/B/C-тест) При 50%: Полная регрессия против каждого варианта При 100%: Финальная валидация, план удаления флага
Лучшие практики
- Очищайте старые флаги. Это технический долг. После полного запуска удалите флаг и старый код.
- Тестируйте поведение fallback. Что произойдёт, если сервис флагов недоступен?
- Никогда не вкладывайте feature flags глубоко. Максимум два уровня вложенности.
- Используйте переопределения флагов в тестовых окружениях.
- Мониторьте изменения состояний флагов. Логируйте когда и кто изменил.