Фича-флаги (feature flags) — это инструмент, который позволяет безопасно и управляемо внедрять новые фичи. С их помощью можно:

✔️ Запускать фичи на ограниченной аудитории: Например, тестировать новую функциональность на 5-10% пользователей, чтобы проверить её стабильность. ✔️ Постепенно расширять охват: Увеличивать количество пользователей, видящих новую фичу, без стресса для команды. ✔️ Управлять доступом по сегментам: Включать функционал только для бета-тестеров, премиум-аккаунтов или других категорий.

🛠️ Фича-флаги и Base Trunk Development

Фича-флаги идеально работают в связке с подходом Base Trunk Development (разработка в основной ветке репозитория). Этот метод позволяет:

✔️Деплоить "сырой" код в основную ветку без риска — фича остаётся выключенной до готовности. ✔️Избежать конфликтов между ветками, так как все изменения сосредоточены в основной ветке. ✔️Быстро итеративно дорабатывать фичи, активируя их только тогда, когда они полностью готовы.

Пример: if (featureFlags.enableDarkMode) { renderDarkMode(); } else { renderLightMode(); } В данном случае флаг enableDarkMode позволяет переключать тему интерфейса, не требуя дополнительных деплоев.

❓ А если флаги — это не только для релизов? Фича-флаги часто рассматриваются как временный инструмент, но что, если их использовать для постоянного управления функционалом? Например:

✔️Разделение функционала между тарифами (базовый, премиум, корпоративный). ✔️Динамическая настройка доступов для разных групп пользователей.

Это добавляет новые вызовы: ❓Как проектировать архитектуру, чтобы избежать путаницы в коде? ❓Как эффективно управлять большим количеством флагов?

🎥 О том, как нам удалось внедрить это в Sendsay и сделать понятную архитектуру, рассказал наш техлид Артем Герус на MoscowJS в Т-банке: https://www.youtube.com/live/XIHCtCwF0hk?t=558s (начало 9:20)