🔛 Фича-флаги: что делать, чтобы не класть весь прод разом
Честно скажу, я совсем недавно узнал, как это на самом деле называется: Feature Flag. Я, в общем-то, всегда звал это просто — рубильник. 💩 Ну да ладно, короче, к сути.
Фича-флаг, он же Feature Toggle, а также Feature Flag (как же чертовски круто это все звучит) — это переключатель, который позволяет включать или выключать функциональность в работающем приложении без перевыпуска кода.
Ну грубо говоря как-то так:
if feature_flag.is_enabled('new_payment_system'):
use_new_payment()
else:
use_old_payment()
После того, как по моим постановкам пару раз положили прод там, где лучше бы этого было не делать, я начал частенько прописывать необходимость рубильника. ✅ (Чтобы я не сидел потом, как эта несчастная псина на картинке).
Зачем вообще это все нужно?
🟣Безопасные релизы. Увидели проблему? ➡️ Выключаем тумблер ➡️ Фича не работает, хотя код уже в проде.
🟣Dark Launches. Можно задеплоить код в прод, но не показывать его пользователям (пока не пришло время).
🟣Условный доступ: включить фичу только для внутренних тестировщиков/конкретной группы пользователей.
🟣Для A/B-тестов, но это для PO, наверное, интересно, я за такое вообще не шарю. 🤷 Просто знаю, что так делают.
Какие есть способы дернуть рубильник?
🔴Таблица в БД: плюс в том, что возможно динамическое изменение без перезапуска. Минусы — нужна соответственно инфраструктура (сама БД).
🔴Переменные окружения. Переключение через .env файл достаточно просто реализовать, но из минусов — переключение флага скорее всего потребует перезапуска.
🔴Конфигурационные файлы (JSON, YAML, TOML, .properties) — примерное те же минусы и плюсы, что в случае с переменными окружения.
🔴Специальные сервисы фича-флагов (их, оказывается, много всяких есть): LaunchDarkly, Split, Flagsmith, Unleash, CloudBees Feature Management. Тут и гибкость в настройке, и изменения в режиме реального времени, но с другой стороны зависимость от еще одного сервиса.
Что важно учитывать:
⚠️ Постараться Не забывать убирать флаги после полного внедрения фичи;
⚠️ Постараться Документировать флаги — какие есть, для чего, кто отвечает;
⚠️ Постараться Не превращать систему в спагетти-код из условий.
In conclusion: Фича-флаги — это не просто технический инструмент, это стратегия безопасной поставки изменений.
#SystemAnalysis #FeatureFlags #Разработка #python #IT #businessanalysis
Честно скажу, я совсем недавно узнал, как это на самом деле называется: Feature Flag. Я, в общем-то, всегда звал это просто — рубильник. 💩 Ну да ладно, короче, к сути.
Фича-флаг, он же Feature Toggle, а также Feature Flag (как же чертовски круто это все звучит) — это переключатель, который позволяет включать или выключать функциональность в работающем приложении без перевыпуска кода.
Ну грубо говоря как-то так:
if feature_flag.is_enabled('new_payment_system'):
use_new_payment()
else:
use_old_payment()
После того, как по моим постановкам пару раз положили прод там, где лучше бы этого было не делать, я начал частенько прописывать необходимость рубильника. ✅ (Чтобы я не сидел потом, как эта несчастная псина на картинке).
Зачем вообще это все нужно?
🟣Безопасные релизы. Увидели проблему? ➡️ Выключаем тумблер ➡️ Фича не работает, хотя код уже в проде.
🟣Dark Launches. Можно задеплоить код в прод, но не показывать его пользователям (пока не пришло время).
🟣Условный доступ: включить фичу только для внутренних тестировщиков/конкретной группы пользователей.
🟣Для A/B-тестов, но это для PO, наверное, интересно, я за такое вообще не шарю. 🤷 Просто знаю, что так делают.
Какие есть способы дернуть рубильник?
🔴Таблица в БД: плюс в том, что возможно динамическое изменение без перезапуска. Минусы — нужна соответственно инфраструктура (сама БД).
🔴Переменные окружения. Переключение через .env файл достаточно просто реализовать, но из минусов — переключение флага скорее всего потребует перезапуска.
🔴Конфигурационные файлы (JSON, YAML, TOML, .properties) — примерное те же минусы и плюсы, что в случае с переменными окружения.
🔴Специальные сервисы фича-флагов (их, оказывается, много всяких есть): LaunchDarkly, Split, Flagsmith, Unleash, CloudBees Feature Management. Тут и гибкость в настройке, и изменения в режиме реального времени, но с другой стороны зависимость от еще одного сервиса.
Что важно учитывать:
⚠️ Постараться Не забывать убирать флаги после полного внедрения фичи;
⚠️ Постараться Документировать флаги — какие есть, для чего, кто отвечает;
⚠️ Постараться Не превращать систему в спагетти-код из условий.
In conclusion: Фича-флаги — это не просто технический инструмент, это стратегия безопасной поставки изменений.
#SystemAnalysis #FeatureFlags #Разработка #python #IT #businessanalysis