Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019

Интересное выступление от Edith Harbaugh, co-founder и CEO платформы для фича флагов LaunchDarkly. В самом начале Edith вспоминает про темные времена, когда она работала в компании, где релизы были раз в полтора года ... и это было быстро, потому что у конкурента они были каждые три года:) Дальше начинается рассказ про паттерны и анти-паттерны их использования. Но до этого хотелось бы обсудить, что сама идея флагов кажется очень простой: нам надо уметь закрывать часть функциональности в коде флагом, который можно удаленно включить/выключить. Это помогает с несколькими вещами

• С feature flags хорошо работает TBD (trunk based development), а без них почти нет
• Release management становится проще (особенно в мобилках)
• Можно тестировать функциональность на части аудитории, например сотрудниках Но тут мы оказываемся на стыке двух миров - работы с кодом и релизами и экспериментами (a/b тесты, сегментация пользователей, персонализация, ...)

Ну а дальше давайте я расскажу про какие вещи говорила Edith

Паттеры и хорошие способы применения флагов

• Feature kill switches - паттерны для отключения фичей на случай проблем или на случай спайка нагрузки
• Мердж бранчей без конфликтов - условно feature flag - это enabler для TBD, про который я уже говорил
• Controlled rollout - условно раскатка порции трафика на новую фичу
• Early access betas для самых лояльных/лучших пользователей
• Для блокировки фичей для некоторых пользователей (например, тех, кому нужны только отстоявшиеся фичи)
• Для тестирования в проде и сокращения важности staging контура (Edith предлагает его вообще убить)
• Для подписок, где часть фичей доступна только по подписке (я думаю, что это странный кейс конечно)
• Для отключения старых фичей

Антипаттерны и косяки

• Кривое наименование флагов - это просто путает и мешает использовать флаги
• Overused flags - одни и те же флаги, которые используются разными командами по разному, условно одни думают, что этот флаг лечит от кашля, а другие, что от запора:)
• Конфликтующие флаги - учитывая комбинаторику, конфликтующие очень легко получить, особенно если не подумать заранее о том, что именно мы закрываем флагами
• Использование флагов для критической функциональности, которая уже давно не должна отключаться - пример с CMS системой, где можно флагом было отключить загрузку файлов, что эффективно отключало всю систему:) Смысл в том, что такой флаг уже давно стал бесмыссленным:)
• Флаги, что остаются в коде и никогда не выпиливаются - это просто ухудшает кодовую базу

Напоследок приводятся рекомендации

• Flag carefully
• Lock down access
• Remove flags

P.S. У нас в компании были разные системы для управления флагами и экспериментами. Сейчас мы идем в сторону общего решения, где

• Базовые сценарии управления флагами будут прямо внутри нашей IDP (internal developer platform) - эта часть про код + release management
• Расширенные сценарии управления будут внутри a/b платформы - это часть про использование флагов для экспериментов, персонализаций, бет и так далее

Если вам нравятся такие задачи и у вас есть опыт промышленной разработки, то вы можете написать мне:)

#Software #Devops #SRE #Reliability #Architecture #Engineering #Processes