Trunk Based Development
На текущей работе мы используем Trunk Based Development (TBD) - методологию разработки, при которой разработчики вносят все изменения кода напрямую в основную ветку репозитория (trunk или main). Новые фичи и фиксы, попадают в trunk, через короткоживущие ветки и частые мерджы. Этот подход отличается от традиционных методологий с долгоживущими независимыми ветками, где каждая фича разрабатывается, а иногда и тестируется в изолированной ветке. Это должно ускорять интеграцию, уменьшать число конфликтов и упростить процесс доставки функциональности в продакшен.
Характерные особенности TBD
- Одна главная ветка - все изменения сливают в основную ветку.
- Небольшие частые комиты - разработчики стараются вностить небольшие изменения как можно чаще, чтобы избежать крупных конфликтов.
- Feature Flags – если функционал не готов, его включают через флаги, а не через ветки.
- Частые релизы - постоянная готовность кода к релизу.
- Короткое время ревью кода - код-ревью должно происходить в короткое время, после открытия мердж-реквеста.
- Непрерывная интеграция (CI) – автоматические тесты и быстрая обратная связь.
Преимущества подхода
- Частые релизы — возможность выпускать обновления чаще, чем при других подходах, за счет постояной готовности основной ветки к релизу.
- Снижение конфликтов — меньше проблем при слиянии кода, так как комиты не большие и частые.
- Упрощённый процесс — единая ветка упрощает управление. Нет сложных стратегий ветвления вроде Git Flow.
- Лучшая командная синхронизация – все работают в одном контексте, частое ревью способствует постоянному обмену знаниями системы.
- Высокий уровень автоматизации. Эффективное применение TBD требует наличия надёжных инструментов для автоматического тестирования и развёртывания, что повышает качество кода и снижает риски.
Недостатки подхода
- Повышенный риск нестабильности - частое слияние в основную ветку может привести к временным сбоям и нестабильностям, которые необходимо исправлять в самое короткое время.
- Нужны Feature Flags – иначе неготовый код попадёт в прод. При большой команде и одновременной разработке связанных фичей могут возникнуть сложные ветвления проверок на флаги.
- Высокие требования к инфраструктуре - применение TDB требует наличия хорошо настроенной системы для автоматического тестирования и развёртывания.
- Сложно с большими фичами и рефакторингом - крупные фичи, рефакторинги или внедрение новой архитектуры потребует изоляции на некоторое время, что невозможно при строгом соблюдении TBD.
- Сложность управления релизами. Подготовка к выпуску новых версий может потребовать дополнительных усилий для изоляции готового функционала от незавершённых задач.
- Не подходит большим командам - большим командам (больше 10 человек) будет сложно, начиная от процессов код-ревью и заканчивая мерджем - даже короткоживущие ветки успевают сильно устареть.
Когда стоит использовать TBD
- Agile-команды с короткими спринтами.
- Микросервисная архитектура.
- Есть CI/CD процессы с автоматизированным тестированием.
- Команды с высокой культурой тестирования - в идеале разработка через TDD.
- Проекты с частыми релизами.
Когда НЕ стоит использовать TBD
- Крупные монолитные системы с частыми критическими изменениями.
- Проекты с жесткими дедлайнами и строго регламентированными релизами.
- Команды без высокой культуры тестирования.
- Отсутствуют автоматизированные процессы развертывания или требуется значительные ручные манипуляции.
- Проекты с длительными экспериментами над кодом.
Заключение
Trunk Based Development — это мощный инструмент для современных команд разработки, который может значительно ускорить процесс разработки и повысить качество кода. Однако, этот подход требует определенной зрелости команды, зрелости процессов и наличия надежной инфраструктуры. А еще раздражает огромное количество Feature Flags в коде :)).
Подпишись на мой канал telegram