Помню времена, когда релиз был похож на прыжок с парашютом: собираем ветку, заливаем в прод, затаив дыхание смотрим на графики. Если что-то падало, начинался откат, горячие правки и ночные звонки. Несколько лет назад я впервые внедрил фича-флаги на одном крупном проекте, и это полностью изменило моё отношение к выкаткам. Теперь я не боюсь выпускать изменения, потому что знаю: у меня есть быстрый выключатель.
Фича-флаг — это простой переключатель, который включает или выключает функциональность без нового деплоя. Для меня это не только «тёмный запуск». Это и аварийный выключатель, и канареечный выкат, и доступ для отдельных пользователей, и эксперименты. Помню случай: новый способ оплаты показывали пяти процентам клиентов. Через час увидели рост ошибок. Я выключил флаг за тридцать секунд, и никто, кроме тестовой группы, ничего не заметил. Никакого отката кода и паники.
Главное, что я понял: фича-флаги требуют дисциплины. У каждого флага должен быть владелец, дата создания и срок жизни. Иначе через полгода код превращается в музей непонятных переключателей. Я завёл правило: если флаг живёт дольше двух месяцев, его нужно либо удалить, либо признать постоянным и задокументировать. Ещё важно называть флаги понятно, чтобы поддержка и аналитики понимали, что именно выключается. И да, значение по умолчанию для нового флага должно быть «выключено».
Про откаты. Фича-флаги дают мгновенное отключение, но они не спасают от плохих миграций базы данных. Если вы удалили колонку, а потом выключили флаг, проблема останется. Поэтому я придерживаюсь принципа обратной совместимости: сначала добавляем новые поля, код умеет работать и со старыми, и с новыми данными, потом выкатываем функциональность, а удаляем лишнее только после полной очистки. Один раз я пренебрёг этим и получил горячий фикс ночью. Больше так не делаю.
Мои рекомендации читателям. Начните с одного рискованного изменения, оберните его в флаг и выкатите сначала на себя или на внутренних пользователей. Затем включите на один процент, затем на пять, на двадцать пять и только потом на всех. Следите не только за ошибками, но и за скоростью, конверсией и обращениями в поддержку. Обязательно заведите журнал изменений флагов: кто, когда и зачем переключил. Если есть возможность, используйте отдельный сервис управления флагами с правами доступа и аудитом.
Ещё один урок: фича-флаги — это не бесплатно. Их нужно тестировать, чистить и мониторить. Но выгода того стоит. Релизы становятся меньше, риск — управляемее, а бизнес быстрее получает обратную связь. Если новая функция не взлетела, её выключают без отката всего релиза. Если взлетела — расширяют аудиторию. В итоге команда меньше геройствует ночами и больше занимается развитием продукта.
Я не считаю фича-флаги серебряной пулей, но для меня это один из самых практичных инструментов в разработке. Они меняют культуру релизов: вместо «держим кулаки» появляется «проверяем, измеряем, выключаем при необходимости». А вы уже используете фича-флаги в своих проектах или пока только присматриваетесь? Поделитесь, какой переключатель однажды спас ваш прод — будет интересно почитать!
Фича-флаг — это простой переключатель, который включает или выключает функциональность без нового деплоя. Для меня это не только «тёмный запуск». Это и аварийный выключатель, и канареечный выкат, и доступ для отдельных пользователей, и эксперименты. Помню случай: новый способ оплаты показывали пяти процентам клиентов. Через час увидели рост ошибок. Я выключил флаг за тридцать секунд, и никто, кроме тестовой группы, ничего не заметил. Никакого отката кода и паники.
Главное, что я понял: фича-флаги требуют дисциплины. У каждого флага должен быть владелец, дата создания и срок жизни. Иначе через полгода код превращается в музей непонятных переключателей. Я завёл правило: если флаг живёт дольше двух месяцев, его нужно либо удалить, либо признать постоянным и задокументировать. Ещё важно называть флаги понятно, чтобы поддержка и аналитики понимали, что именно выключается. И да, значение по умолчанию для нового флага должно быть «выключено».
Про откаты. Фича-флаги дают мгновенное отключение, но они не спасают от плохих миграций базы данных. Если вы удалили колонку, а потом выключили флаг, проблема останется. Поэтому я придерживаюсь принципа обратной совместимости: сначала добавляем новые поля, код умеет работать и со старыми, и с новыми данными, потом выкатываем функциональность, а удаляем лишнее только после полной очистки. Один раз я пренебрёг этим и получил горячий фикс ночью. Больше так не делаю.
Мои рекомендации читателям. Начните с одного рискованного изменения, оберните его в флаг и выкатите сначала на себя или на внутренних пользователей. Затем включите на один процент, затем на пять, на двадцать пять и только потом на всех. Следите не только за ошибками, но и за скоростью, конверсией и обращениями в поддержку. Обязательно заведите журнал изменений флагов: кто, когда и зачем переключил. Если есть возможность, используйте отдельный сервис управления флагами с правами доступа и аудитом.
Ещё один урок: фича-флаги — это не бесплатно. Их нужно тестировать, чистить и мониторить. Но выгода того стоит. Релизы становятся меньше, риск — управляемее, а бизнес быстрее получает обратную связь. Если новая функция не взлетела, её выключают без отката всего релиза. Если взлетела — расширяют аудиторию. В итоге команда меньше геройствует ночами и больше занимается развитием продукта.
Я не считаю фича-флаги серебряной пулей, но для меня это один из самых практичных инструментов в разработке. Они меняют культуру релизов: вместо «держим кулаки» появляется «проверяем, измеряем, выключаем при необходимости». А вы уже используете фича-флаги в своих проектах или пока только присматриваетесь? Поделитесь, какой переключатель однажды спас ваш прод — будет интересно почитать!