Фича-флаг (фича-тогл)

Experimenta est optima rerum magistra

Речь, собственно, о фрагменте кода, позволяющем продакту одним движением в админке включать и выключать конкретные фичи.

Вводная

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

С точки зрения разработки, программист может выливать на прод фрагменты фичи и тут же проверять их работу. Пользователи при этом фичу не видят. В отличие от традиционного подхода, когда фича выливается на прод целиком и могут возникнуть ошибки, этот подход позволяет их избежать.

Итак, выливаем фичу по частям, тестируем по частям, пока фича не будет готова полностью потом релизим её целиком, проводим регресс, настраиваем аналитику и продакт может «дёрнуть рубильник», показав уже вылитую фичу юзерам. Если же подход не помог и фича всё же вызвала критическую проблему, нет никакой проблемы «дёрнуть рубильник» обратно и фичу тут же убрать для доработки.

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

Как работают тоглы

Разберём чуть подробнее, как работают тоглы.

С технической точки зрения, самый простой вариант — банальный IF¹, завязанный на флаг в админке, который включает и выключает фичу.

Посмотрите, как это делают в Авито:

const PurchaseListFeature = "some-string"
func (s *Service) Handle {
...
  // проверим, включена ли фича
  if (s.FeatureFlags.IsEnable(PurchaseListFeature)) {
    // делаем запрос в сервис, за списком покупок
    purchases := s.purchasesRepository.GetLast(limit, userID)
    // Добавим список покупок к ответу
    result["purchases"] = purchases
  }  
...
}

Если заморочиться, можно сделать параметры посложнее: запуск фичи по расписанию или только для пользователей с определённым уровнем доступа или даже автоматическое отключение при достижении определённого уровня нагрузки на систему.

Способы применения тоглов

Технически тоглы работают одинаково, способы применения же можно выделить следующие:

• Релизные (release toggles): скрывают неготовые фичи, уменьшают количество веток, открепляют запуск фичи от даты деплоя. Это тот самый флаг, о котором я писал в начале статьи.
• Экспериментальные (experiment toggles): это более тонкая штука, инструмент продакта для A\B тестирования², выкатки фичи только на небольшую группу пользователей для изучения поведения и сбора первого фидбека.
• Разрешающие (permission toggles): это нужно, чтобы скрыть платные фичи от неоплативших или чтобы сделать фичи только для администратора.
• Операционные (ops toggles): нужны для отключения ресурсоёмких операций. Например, если вы решили делать какие-то вычисления на фронте и есть необходимость отключить их на смартфоне. Или хотите застраховаться от неконтролируемого роста нагрузки, вызванного ошибками в свежевыкаченной фиче.

Применение тоглов в микросервисной архитектуре

Что же делать, если у вас микросервисы? Сделать сервис тоглов и вынести их туда? Плохая идея, потому что:

• нет явной связи между сервисами;
• может получиться асинхронный монолит, а не микросервисы;
• придётся ждать релиза всех сервисов, где есть тоггл, прежде чем его включать;
• включение и выключение — всегда огромный риск: не предугадаешь, где и что бомбанёт.

Как будет правильно?

Отдельные тоглы на каждый микросервис.

Это самый правильный подход. Дублируем тоглы в каждом сервисе, делаем их включаемыми и отключаемыми, независимо от других. Важно то, что эти тоглы нигде больше не используются.

Этот подход работает лучше, потому что: 

• Каждый сервис изначально не рассчитывает на то, что тоглы будут включены одновременно;
• Нет неявных связей между сервисами;
• Тестирование тоггла будет происходить внутри одного сервиса и влиять только на него.
• Ваши сервисы не превращаются в распределенный монолит.

Существующие решения для фича-флагов

Какие существуют решения для управления тоглами:

• Проприетарные решения: LaunchDarkly, Bullet-Train, Unleash. У каждого свои плюсы и минусы, все нужно дополнительно конфигурировать силами разработчиков.
• Open source решения: Moggles, Esquilo. С опенсорсом, конечно, больше геморроя, но вы избавлены от лицензионных отчислений и вольны конфигурировать их как угодно.
• Собственное решение. Любители городить собственные огородики ничем в этом отношении не ограничены.

1. Ветвление в программировании, ЕСЛИ условие соблюдается, выполняется первая группа кода, ИНАЧЕ выполняется вторая группа кода. Есть практически в любом языке программирования. ↩︎
2. Это тип тестирования, при котором группе А фичу отображают, а группе В — нет. После некоторого временного промежутка измеряют ключевые метрики, если они для группы А улучшились, значит, тестирование прошло успешно. И наоборот, если ухудшились — значит, фича скорее вредит, чем помогает. ↩︎