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, повнофункціональний), Firebase Remote Config (безкоштовно для малих проектів), Split.io (open-source). Вони надають: цільове ввімкнення фіч за відсотком користувачів, A/B-тестування, моніторинг використання та автоматичне вимкнення при помилках. В мобільних проектах Firebase Remote Config — найпопулярніший вибір через інтеграцію з Firebase та безкоштовний поріг до 1000 користувачів.