Катим в прод | Александр Калыргин
25.12 · ред.
🛠 Как фича-тогллы могут упростить жизнь
Фича-тогглы позволяют включать и выключать фичи в реальном времени без необходимости привлекать программистов. Конечно, этот подход не всегда применим. Для сложных продуктов с взаимозависимыми фичами он может стать избыточным. Однако если ваш продукт состоит из независимых фич, фича-тогглы могут значительно упростить жизнь продактам. Например, продакт может включить нужную фичу одной галочкой в админке или, наоборот, отключить её, если начали поступать жалобы — тоже одной галочкой. Всё без вмешательства программистов! 🚀 Для разработки С технической стороны, фича-тоггл позволяет программистам выкатывать фичи по частям, тестировать их по частям, и только когда фича полностью готова, включать её для пользователей. Это снижает риски: ошибки не попадут в продакшн, пока не будут тщательно проверены. Если вдруг фича вызвала критические проблемы, можно быстро откатить изменения без необходимости выкатки нового релиза — достаточно просто выключить тоггл. 🔧 Когда это работает? Этот подход актуален для больших продуктов с множеством независимых фич, где работает несколько продактов. Для маленьких продуктов на ранних этапах его использование может быть избыточным. 💡 Как работают тогглы? Самый простой пример — использование условия if на основе флага в админке: const PurchaseListFeature = "some-string" _func (s Service) Handle { … // проверим, включена ли фича_ if (s.FeatureFlags.IsEnable(PurchaseListFeature)) { // делаем запрос в сервис, за списком покупок purchases := s.purchasesRepository.GetLast(limit, userID) // Добавим список покупок к ответу result["purchases"] = purchases } … } Для более сложных случаев можно добавить: - Запуск фичи по расписанию 🕓 - Ограничение доступа для определённых пользователей 🔐 - Автоматическое отключение при перегрузке системы ⚡️ ⚙️ Типы тогглов 1️⃣ Релизные (Release toggles): скрывают неготовые фичи, позволяя запускать их независимо от даты деплоя. 2️⃣ Экспериментальные (Experiment toggles): используются для A/B тестирования, выпуска фичи на небольшую группу пользователей. 3️⃣ Разрешающие (Permission toggles): для скрытия платных фич от неоплативших пользователей или фич только для администраторов. 4️⃣ Операционные (Ops toggles): позволяют отключать ресурсоёмкие операции или застраховаться от перегрузки системы. 🏗 Микросервисы и тогглы* Если у вас микросервисная архитектура, не стоит выносить фича-флаги в общий сервис, так как это может привести к асинхронному монолиту. Лучше создать отдельные тогглы для каждого микросервиса. Это обеспечит независимость, лучшее тестирование и минимальные риски при включении и выключении флагов. Катим в прод
Михаил Кузьмин
· 28.12
Только вот проектировать надо так, чтобы тоглить можно было бы и фронт, и кучу микросервисов, и смежников, и в особо извращенных случаях - БД. И то, как одни фичи аффектят другие. Получается в итоге пердольня космических масштабов.
ответить
еще контент в этом сообществе
еще контент в этом соообществе
Катим в прод | Александр Калыргин
25.12 · ред.
войдите, чтобы увидеть
и подписаться на интересных профи