Experimenta est optima rerum magistra
Речь, собственно, о фрагменте кода, позволяющем продакту одним движением в админке включать и выключать конкретные фичи.
Вводная
Этот подход усложняет разработку и с некоторыми фичами в некоторых продуктах просто невозможен. Но если продукт состоит из более-менее самостоятельных фич, тогл сильно облегчит работу продакта, который сможет активировать исследования установкой одной галки в админке или напротив, отключать фичи, на которые начался поток жалоб, тоже одной галкой, без привлечения программистов.
С точки зрения разработки, программист может выливать на прод фрагменты фичи и тут же проверять их работу. Пользователи при этом фичу не видят. В отличие от традиционного подхода, когда фича выливается на прод целиком и могут возникнуть ошибки, этот подход позволяет их избежать.
Итак, выливаем фичу по частям, тестируем по частям, пока фича не будет готова полностью потом релизим её целиком, проводим регресс, настраиваем аналитику и продакт может «дёрнуть рубильник», показав уже вылитую фичу юзерам. Если же подход не помог и фича всё же вызвала критическую проблему, нет никакой проблемы «дёрнуть рубильник» обратно и фичу тут же убрать для доработки.
Фича-флаг в большей степени актуален для больших продуктов, с которыми работает несколько продактов, этот подход очень хорошо стабилизирует разработку. Для маленьких продуктов и софта на ранних этапах развития он, конечно, избыточен.
Как работают тоглы
Разберём чуть подробнее, как работают тоглы.
С технической точки зрения, самый простой вариант — банальный IF1, завязанный на флаг в админке, который включает и выключает фичу.
Посмотрите, как это делают в Авито:
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 тестирования2, выкатки фичи только на небольшую группу пользователей для изучения поведения и сбора первого фидбека.
- Разрешающие (permission toggles): это нужно, чтобы скрыть платные фичи от неоплативших или чтобы сделать фичи только для администратора.
- Операционные (ops toggles): нужны для отключения ресурсоёмких операций. Например, если вы решили делать какие-то вычисления на фронте и есть необходимость отключить их на смартфоне. Или хотите застраховаться от неконтролируемого роста нагрузки, вызванного ошибками в свежевыкаченной фиче.
Применение тоглов в микросервисной архитектуре
Что же делать, если у вас микросервисы? Сделать сервис тоглов и вынести их туда? Плохая идея, потому что:
- нет явной связи между сервисами;
- может получиться асинхронный монолит, а не микросервисы;
- придётся ждать релиза всех сервисов, где есть тоггл, прежде чем его включать;
- включение и выключение — всегда огромный риск: не предугадаешь, где и что бомбанёт.
Как будет правильно?
Отдельные тоглы на каждый микросервис.
Это самый правильный подход. Дублируем тоглы в каждом сервисе, делаем их включаемыми и отключаемыми, независимо от других. Важно то, что эти тоглы нигде больше не используются.
Этот подход работает лучше, потому что:
- Каждый сервис изначально не рассчитывает на то, что тоглы будут включены одновременно;
- Нет неявных связей между сервисами;
- Тестирование тоггла будет происходить внутри одного сервиса и влиять только на него.
- Ваши сервисы не превращаются в распределенный монолит.
Существующие решения для фича-флагов
Какие существуют решения для управления тоглами:
- Проприетарные решения: LaunchDarkly, Bullet-Train, Unleash. У каждого свои плюсы и минусы, все нужно дополнительно конфигурировать силами разработчиков.
- Open source решения: Moggles, Esquilo. С опенсорсом, конечно, больше геморроя, но вы избавлены от лицензионных отчислений и вольны конфигурировать их как угодно.
- Собственное решение. Любители городить собственные огородики ничем в этом отношении не ограничены.
- Ветвление в программировании, ЕСЛИ условие соблюдается, выполняется первая группа кода, ИНАЧЕ выполняется вторая группа кода. Есть практически в любом языке программирования. ↩︎
- Это тип тестирования, при котором группе А фичу отображают, а группе В — нет. После некоторого временного промежутка измеряют ключевые метрики, если они для группы А улучшились, значит, тестирование прошло успешно. И наоборот, если ухудшились — значит, фича скорее вредит, чем помогает. ↩︎