Trunk-Based Development — что это, принципы и работа в одной ветке

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

Trunk-Based Development (TBD) — методология управления версиями, при которой все разработчики интегрируют свои изменения в единственную основную ветку (trunk, main или master) несколько раз в день. В отличие от Git Flow с его долгоживущими feature-ветками, TBD минимизирует время жизни веток до нескольких часов, реже — до 1–2 дней. Основная цель — избежать «ада слияния» (merge hell), когда большая фича сливается с trunk спустя недели разработки.

По данным Google Cloud DevOps, 2024, Trunk-Based Development — одна из ключевых практик высокопроизводительных DevOps-команд. Исследование State of DevOps Report (Puppet, 2023) показало, что команды, использующие TBD, на 30% быстрее восстанавливаются после сбоев и на 50% реже сталкиваются с критическими дефектами в продакшне. TBD обязателен для Continuous Deployment.

Trunk-Based Development не означает, что разработчики коммитят напрямую в trunk без проверки. В TBD используются короткоживущие feature-ветки, которые после создания MR и быстрого код-ревью (в течение нескольких часов) вливаются в trunk. Если ревью занимает больше одного дня — значит, фичу нужно декомпозировать на более мелкие части.

State of DevOps Report: данные о TBD

Ежегодный State of DevOps Report (Puppet/DORA) отслеживает практики высокопроизводительных команд. С 2015 года TBD входит в топ-3 практик, коррелирующих с высокой частотой поставки (deploy frequency) и низким временем восстановления (MTTR). Команды, практикующие TBD, развёртывают код в 2–3 раза чаще и восстанавливаются после сбоев на 30% быстрее (DORA, 2023).

Feature Toggles: управление неготовым кодом без веток

Feature Toggles (флаги фич, feature flags) — механизм включения и отключения функциональности без изменения кода. В TBD feature toggles заменяют feature-ветки: разработчик коммитит неготовый код в trunk, но скрывает его за условным флагом. Когда фича готова к показу, флаг переключается в конфигурации без повторного деплоя.

По данным Martin Fowler, 2024, feature toggles делятся на четыре типа: release toggles (управление видимостью фичи), experiment toggles (A/B-тестирование), ops toggles (управление операционными параметрами) и permission toggles (доступ по ролям). В мобильных проектах release toggles особенно полезны: новая функциональность скрыта до даты релиза, но код уже в trunk и проходит CI/CD.

// Feature Toggle в Android на Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Использование в коде
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD в Trunk-Based Development: обязательные практики

Continuous Integration (CI) — самый важный компонент TBD. Каждый push в trunk (или во временную ветку перед MR) запускает полный пайплайн: сборка, модульные тесты, интеграционные тесты, линтеры, статический анализ, проверка покрытия кода. Если хотя бы один этап падает — автор изменений исправляет код до следующего коммита. «Сломанный trunk — остановленная разработка» — главное правило TBD.

По данным Jez Humble, Continuous Delivery, 2024, Trunk-Based Development требует CI-пайплайна, который выполняется за 10–15 минут. Если сборка дольше — разработчики реже коммитят, а это разрушает смысл TBD. В мобильных проектах Android и iOS сборка может длиться 20–30 минут, что делает TBD менее удобным. В таких случаях команды используют Short-Lived Feature Branches (ветки на 1 день) с немедленным CI.

# GitHub Actions для TBD (Android)
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Короткоживущие ветки: правила работы в TBD

Короткоживущие ветки (short-lived branches) — компромисс между чистым TBD (коммиты напрямую в trunk) и Git Flow. Ветка живёт не более 1–2 дней, содержит изменения на 1–3 коммита и после ревью (не более 4 часов ожидания) вливается в trunk. Если фича требует больше времени — её делят на подзадачи, каждая со своей короткоживущей веткой.

По данным TBD Documentation, 2024, правила короткоживущих веток: ветка создаётся от свежего trunk (не старше 1 часа), не синхронизируется с trunk через merge/rebase (если прошло больше 4 часов — создаётся новая ветка), MR/PR создаётся сразу после первого коммита (даже если работа не завершена — как Draft).

Pre-tested commits: коммиты с гарантией

Для Trunk-Based Development важна техника pre-tested commits: разработчик перед коммитом запускает CI-пайплайн в своей ветке, и только после зелёного статуса коммит попадает в trunk. В GitLab это реализуется через Merge Request pipelines с опцией «Merge when pipeline succeeds». В GitHub — через branch protection rules с Required status checks. Это гарантирует, что trunk никогда не содержит сломанного кода.

• 1–2 дня — максимальное время жизни short-lived branch
• 1–3 коммита — оптимальный размер изменений
• 4 часа — максимальное время ожидания код-ревью
• Создавай MR сразу после первого коммита, даже в Draft-статусе

Branch by Abstraction: замена кода без ветвления

Branch by Abstraction — техника, позволяющая заменить или существенно изменить часть системы без создания долгоживущей feature-ветки. Вместо ветвления в Git разработчик создаёт абстракцию (интерфейс), под которой работают и старая, и новая реализации. Постепенно все потребители переводятся на новую реализацию, после чего старая удаляется.

По данным Branch by Abstraction, 2024, этапы Branch by Abstraction: 1) создать абстракцию для заменяемого компонента, 2) реализовать новую версию под абстракцией, 3) переключить потребителей на новую реализацию через конфигурацию, 4) удалить старую реализацию. Все шаги коммитятся в trunk маленькими порциями, каждая из которых не ломает CI/CD.

TBD vs Git Flow: сравнение подходов

Trunk-Based Development и Git Flow — два противоположных подхода к управлению ветками. Git Flow использует долгоживущие ветки и строгую иерархию, TBD — одну ветку и короткие циклы интеграции. Выбор между ними зависит от размера команды, частоты релизов и уровня CI/CD-автоматизации.

Типичные ошибки при внедрении Trunk-Based Development

Ошибки TBD чаще всего связаны с недостаточным CI/CD или слабой дисциплиной коммитов. Первая ошибка — внедрение TBD без CI, которое ломается с первого же неудачного коммита. Если trunk нельзя починить за 15 минут — команда теряет доверие к процессу и возвращается к долгим веткам. Вторая — разрешение долгоживущих веток «исключительно для этой фичи», что разрушает всю концепцию.

По данным Paul Hammant, 2023, третья ошибка — плохая модульность кода. Trunk-Based Development требует, чтобы код был разбит на независимые модули. Если изменение в одном классе ломает три других модуля — разработчики не могут коммитить маленькими порциями. Четвёртая — игнорирование feature toggles: попытка коммитить незавершённый код без флага приводит к поломке trunk для всей команды.

Trunk-Based Development в мобильной разработке

Trunk-Based Development в мобильных проектах имеет особенности из-за длительной сборки (20–30 минут для Android и iOS) и строгих требований к качеству. Google и Spotify используют TBD в мобильной разработке, применяя short-lived branches с обязательным прохождением CI перед мержем. Feature toggles управляются через Firebase Remote Config или LaunchDarkly.

По данным LaunchDarkly Docs, 2024, в мобильной разработке TBD даёт преимущество: функции тестируются в trunk вместе с остальным кодом до даты релиза, что снижает риск интеграционных проблем. Если CI-пайплайн занимает более 15 минут — оптимальны short-lived branches на 1 день с автоматическим CI при каждом push. Для Apple App Store и Google Play TBD требует настройки staged rollouts через feature toggles.

Feature Flags как сервис: LaunchDarkly и Firebase

Для управления feature toggles в TBD используются платформы: LaunchDarkly (enterprise, full-featured), Firebase Remote Config (бесплатно для малых проектов), Split.io (open-source). Они предоставляют: целевое включение фич по проценту пользователей, A/B-тестирование, мониторинг использования и автоматическое отключение при ошибках. В мобильных проектах Firebase Remote Config — самый популярный выбор из-за интеграции с Firebase и бесплатного порога до 1000 пользователей.