Trunk Based Development: как ускорить релизы без потери качества

Компании стремятся выпускать обновления чаще, чтобы доставлять пользователям новые возможности, устранять баги и адаптироваться к бизнесу. Особенно это актуально в архитектурах на базе микросервисов, где множество команд работают над независимыми частями системы.

В этой статье мы расскажем, как подход Trunk Based Development (TBD) помогает справляться с этими вызовами.

Что такое Trunk Based Development?

Trunk Based Development — это стратегия работы с кодом, при которой вся команда разрабатывает новые фичи и делает исправления напрямую в основной ветке (обычно main или master). В отличие от популярных моделей вроде Git Flow, где работа ведется в долгоживущих ветках, TBD предполагает частые маленькие коммиты в trunk.

Преимущества:

• Уменьшение количества merge-конфликтов. 
• Быстрая интеграция изменений. 
• Прозрачная история разработки. 
• Возможность в любой момент после релиза включить флаг с новой фичей на проде. 
• Возможность откатить изменения на проде просто выключив фиче-флаг. 

Такая практика особенно хорошо работает в связке с feature flags, автоматическим тестированием и CI/CD, гарантируя частые, уверенные релизы.

Микросервисная архитектура отлично сочетается с таким методом. Поскольку команды работают независимо, важна синхронизация на уровне trunk, а не координация между десятками веток. TBD помогает избежать конфликтов при слиянии, ускоряет тестирование, а CI/CD-инфраструктура автоматически собирает и выкатывает обновления. В результате каждая команда может поставлять ценность пользователям без лишней бюрократии и зависимости от других. А бизнес сам решает, какие фичи и в какой момент сделать доступными для пользователей после релиза.

Как устроен процесс TBD

Внедрение Trunk Based Development требует определенной дисциплины и зрелости процессов:

• Частые коммиты и короткие ветки 

Обычно изменения делаются в короткоживущих ветках (иногда даже без них) и вливаются в trunk за считанные часы. 

• Feature toggles 

Чтобы можно было сливать незавершенный функционал, быстро включать и откатывать его, используются флаги фич — переключатели, управляющие доступностью кода в продакшне.

• Автоматизация через CI/CD 

Каждый пуш в trunk запускает тесты, сборку и деплой. Важно, чтобы пайплайн CI/CD был быстрым и надежным.

• Код-ревью

Несмотря на скорость, TBD не отменяет качества. Каждое изменение должно быть проверено хотя бы одним другим разработчиком.

Для бизнеса этот подход дает значительное преимущество. Снижается время выхода обновлений, уменьшаются риски, повышается стабильность поставки. Продукт становится более гибким, команды — более автономными. Можно экспериментировать, быстрее проверять гипотезы, реагировать на изменения рынка, отключать фичи если что-то пошло не так. Все это — без необходимости усложнять git-историю или бороться с конфликтами при масштабных слияниях.

Но TBD – не идеальный рецепт, когда «включил и все заработало». Здесь тоже есть свои нюансы и сложности, которые возникают, если не соблюсти определенные условия:

• если нет достаточного покрытия тестами - возникают сложности с контролем качества,
• если не настроены фиче - флаги - недостаточная изоляция фич, 
• если декомпозиция слишком крупная - появляется неудобство при долгих и сложных фичах, которые не укладываются в короткие коммиты,
•  если CI нестабилен или релизы происходят без мониторинга, выпуск обновлений становятся стрессовым.

Теперь, когда с теорией покончено – перейдем к практике.

Как TBD работает в нашей команде

В начале 2020 года в True Engineering мы сформировали стратегию «Общего инжиниринга», в рамках которой создавалась собственная методологическая база и стандарты, а также рабочие процессы приводились к единому формату.

Одним из этапов трансформации стал переход на методологию разработки Trunk Based Development.

До TBD мы использовали GitFlow. Тогда все работало так: функционал разбит на четкие версии, фича сделана, долго тестируем - и выпускаем релиз. GitFlow и подобные ему схемы хороши, когда происходят заметные изменения версий - например, переход от версии 2 к новой версии 3, может даже с разными командами на каждой. Но когда обновления постоянные и быстрые, все это начинает мешать: ветки висят месяцами, появляются конфликты при мердже, процесс становится непредсказуемым.

Переход именно на TBD был продиктован стремлением следовать современным подходам в продуктовой разработке, быстро доставлять изменения, быстро тестировать гипотезы, быстро откатиться при необходимости. Сейчас это уже стандарт индустрии.

Во-первых, TBD особенно хорошо работает в условиях, когда продукт развивается непрерывно. Во-вторых, это связано с микросервисной архитектурой. Мы хотим обновлять микросервисы независимо друг от друга. Если бы мы придерживались не TBD, а, например, того же GitFlow, то, чтобы обновить версию, нам бы приходилось обновлять все микросервисы сразу. В случае с TBD мы можем обновить конкретный микросервис, залить его в мастер-ветку, но переключить фиче-флаг только в тот момент, когда другие микросервисы будут готовы.

Сам переход на TBD происходил не одномоментно, мы постепенно внедряли изменения в командах, объясняли принципы, готовили инструменты, повышали покрытие тестами, чтобы все заработало. Сейчас уже около 90% активно развиваемых продуктов у нас работают по TBD.

Внутренние правила

Для TBD у нас действуют общие требования к коду, который пушится в основную ветку:

1. Фиче-флаг: код должен быть закрыт фиче-флагом — должна быть возможность включить/выключить его.
2. Код-ревью: обязательно проводится ревью кода.
3. Автоматизированное тестирование: как минимум юнит-тесты должны успешно проходить.
4. Регулярные пересмотр фиче-флагов: команда регулярно делает ревью флагов, удаляет ненужные с тем, чтобы в коде было чисто.

На этапе аналитики вместе с командой заранее определяется, какие фиче-флаги нужны и как они будут влиять на поведение системы. Затем идет реализация, и тестировщики проверяют фичу в разных окружениях, включая/отключая флаги через наш собственный портал.

Портал Feature Flag - наш первый продукт, который мы выпустили в open source. Через портал владельцы продукта или другие стейкхолдеры могут самостоятельно включать и выключать необходимые функции, не привлекая к этому команду разработки. Также любой разработчик может не только внедрить портал у себя на проекте, но и вносить изменения в код продукта, тем самым развивая и совершенствуя его. Портал в открытом доступе на GitHub.

Как это повлияло на скорость разработки

TBD и фичи-флаги добавляют некоторый постоянный «оверхед», но это компенсируется тем, что исчезает хаос с мерджем, который в случае GitFlow мог длиться месяцами, когда тяжело планировать: вроде все разработано, но, когда это реально попадет в прод — непонятно. TBD делает процесс предсказуемым. Времени уходит чуть больше на добавление флагов, тестирование и удаление ненужных флагов, но взамен исчезают непредсказуемые и трудозатратные этапы интеграции.

Заключение

Trunk Based Development дает честное преимущество для быстроразвивающихся цифровых продуктов на базе микросервисов. Однако, это не универсальное решение. Такой подход требует зрелых инженерных процессов. Об этом важно помнить, чтобы на выходе получить скорость, гибкость и качество разработки.