Долгоживущие ветки — тихий налог на скорость команды. Чем дольше ветка живет в стороне от мастера, тем болезненнее слияние: чужой код уехал вперед, ваш — устарел, а «merge hell» съедает часы, которые хотелось потратить на продукт. Trunk-based development предлагает обратное: все коммитят в один ствол (trunk) маленькими порциями и часто, по нескольку раз в день.
Но тут возникает честный вопрос: как выкатывать в мастер незавершенную функциональность и при этом не показывать ее пользователям? Ответ — feature toggles. Код едет в продакшн «под замком»: флаг выключен, и пользователь видит старое поведение. Когда фича готова — флаг включается, без нового деплоя. Так деплой (доставка кода на сервер) и релиз (открытие фичи людям) перестают быть одним и тем же событием.
Это разделение — главная идея. Деплой становится техническим, рутинным и безопасным; релиз — продуктовым решением, которое можно принять в любой момент и так же быстро отменить. Разработчик мержит незаконченный код за флагом хоть каждый день, а бизнес открывает фичу тогда, когда готов.
Флаги бывают разными по времени жизни, и путать их вредно. Release-тогглы прячут незавершенные фичи и удаляются сразу после полного выката. Experiment-тогглы обслуживают A/B-тесты и живут недели. Ops-тогглы (kill switch) позволяют аварийно отключить тяжелую функцию под нагрузкой. Permission-тогглы открывают возможности отдельным сегментам — например, бета-группе.
На Unleash все это превращается в инфраструктуру, а не в россыпь if-ов: централизованное хранилище флагов, стратегии выката (по проценту, по сегменту, по атрибутам), аудит «кто и когда переключил» и мгновенный откат. Сломалось на проде — выключили тоггл за секунду, а не катим хотфикс двадцать минут под аккомпанемент алертов.
У подхода есть цена, о которой честно стоит сказать, — дисциплина. Trunk-based не работает без хорошего CI и автотестов — иначе частые коммиты в ствол превратят его в минное поле. И флаги нужно убирать: мертвый тоггл, оставшийся «на всякий случай» на год, — это технический долг и лишняя ветка логики. Хорошая практика — заводить тикет на удаление флага сразу при его создании.
Как это выглядит в жизни: заводишь флаг, прячешь за ним новую логику, мержишь в мастер маленькими PR-ами, катишь на 1–5% пользователей, смотришь метрики, расширяешь до 100% — и удаляешь флаг. Если на любом шаге что-то идет не так, откат занимает один клик.
Результат в цифрах, которые я видел на практике: время выката новых фич падает примерно на 30%, а число production-инцидентов — примерно на 25%, потому что «откатить» теперь значит «щелкнуть тумблером», а не собирать релиз заново. Trunk-based снимает боль слияний; feature toggles снимают страх релиза. Вместе они и есть то, что называют непрерывной доставкой.