Feature toggling, также называемый feature flagging — это механизм включения/выключения фич в продукте через простую конфигурацию. Например, у нас есть новая фича, которую мы тестируем с бета пользователями. На стороне серверной конфигурации мы прописываем у кого должен быть доступ и фича включается у отдельных юзеров.

Обычно это выглядит так:

1. На клиенте (в приложении, вебаппе, или даже API) есть кусок кода, к которому мы хотим ограничить доступ. Этот код обнесён простым if, который делает запрос к сервису feature toggling в формате "есть у пользователя userId доступ к фиче featureId"? Если сервис говорит, что доступ надо дать, показываем фичу. Если нет — соответственно, не показываем.
2. На стороне сервиса Feature Toggling есть конфигурация, в которой для каждой featureId прописаны критерии доступа. На самом базовом уровне мы можем прописать идентификаторы пользователей, у которых есть доступ. Или идентификатор компании, чьи пользователи имеют доступ (в сегменте B2B). Или условия вроде "если аккаунт был создан до июля 2024 года && пользователь находится в такой-то стране" для более сложных сценариев. Или "внутренний пользователь из отдела Х" — в таком случае сервис может даже коммуникировать с другими системами внутри компании, чтобы определить уровень доступа.
3. Есть также значение по умолчанию. Если вдруг нет доступа к сервису feature toggling, то клиентский код должен знать, что делать дальше. Если ответа нет, значит доступа нет. Ну или наоборот есть в случаях, когда мы хотим удалить фичу.
4. Когда мы выкатываем не новую фичу, а меняем старую, то метрики из приложения должны учитывать значения toggle, чтобы можно было анализировать разницу между новым и старым. Feature toggling — это база для A/B тестирования. FT может распределять пользователей по группам в том числе и рандомно, а "A/B тестирование" заключается в анализе результатов между группами.

Feature Toggling — незаменимый механизм для высокой скорости разработки.

Работа над фичами может занимать недели и даже месяцы. Если разработчики работают над фичей в отдельной ветке (branch), то их копия кода устаревает, её нужно постоянно синхронизировать с работой других разработчиков, возникают конфликты в коде и т.п. Это ад даже в команде из 3-4 человек, а в команде, где над кодовой базой работают 10+ человек, это будет прям совсем неэффективно.

Поэтому важно делать небольшие изменения в коде и регулярно пушить их в основную ветку (main), которая сразу же идёт в продакшен.

ЧТО??? ТЕСТИРУЕМ КОД В ПРОДАКШЕНЕ???

Конечно. Именно так.

Но тут нам на помощь приходят feature toggles!

На ранних этапах, когда всё очень криво, даём доступ только для команды, потом расширяем до внутренних пользователей, потом начинаем добавлять рисковых бета-юзеров, а потом уже одним переключением рубильника "выкатываем" в прод фичу, код которой уже и так давно в проде.

Где тут продакт менеджмент?

Понимая, что такое feature toggling, РМы должны настаивать на использовании этого механизма для более раннего доступа к фичам. Создать такой механизм не так сложно или можно использовать платный сервис типа LaunchDarkly.

Если к вам приходят разработчики и говорят, что хотят сделать feature toggles, их нужно обнять и купить им за такое дело овсяный латте, а не хлопать глазками с вопросом "чтобы что? скока бабла это принесёт?"