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