Trunk-Based Development — co to je, principy a práce v jedné větvi

Co je Trunk-Based Development?

Trunk-Based Development (TBD) — metodologie správy verzí, při které všichni vývojáři integrují své změny do jediné hlavní větve (trunk, main nebo master) několikrát denně. Na rozdíl od Git Flow s jeho dlouhožijícími feature-větvemi, TBD minimalizuje životnost větví na několik hodin, výjimečně na 1–2 dny. Hlavním cílem je vyhnout se „peklu slučování" (merge hell), když je velká funkce sloučena s trunk po týdnech vývoje.

Podle Google Cloud DevOps, 2024, je Trunk-Based Development jednou z klíčových praktik vysoce výkonných DevOps týmů. Výzkum State of DevOps Report (Puppet, 2023) ukázal, že týmy používající TBD se o 30 % rychleji zotavují z poruch a o 50 % méně často narážejí na kritické vady v produkci. TBD je povinný pro Continuous Deployment.

Trunk-Based Development neznamená, že vývojáři commit přímo do trunk bez ověření. V TBD se používají krátkožijící feature-větve, které se po vytvoření MR a rychlé code review (během několika hodin) sloučí do trunk. Pokud review trvá déle než jeden den — znamená to, že funkci je třeba rozdělit na menší části.

State of DevOps Report: údaje o TBD

Výroční State of DevOps Report (Puppet/DORA) sleduje praktiky vysoce výkonných týmů. Od roku 2015 je TBD v top 3 praktik korelujících s vysokou frekvencí dodávání (deploy frequency) a nízkou dobou obnovy (MTTR). Týmy praktikující TBD nasazují kód 2–3krát častěji a zotavují se z poruch o 30 % rychleji (DORA, 2023).

Feature Toggles: správa nedokončeného kódu bez větví

Feature Toggles (přepínače funkcí, feature flags) — mechanismus zapínání a vypínání funkcionality bez změny kódu. V TBD nahrazují feature toggles feature-větve: vývojář commit nedokončený kód do trunk, ale skryje jej za podmíněným přepínačem. Když je funkce připravena k zobrazení, přepínač se přepne v konfiguraci bez opětovného nasazení.

Podle Martin Fowler, 2024, se feature toggles dělí na čtyři typy: release toggles (správa viditelnosti funkce), experiment toggles (A/B testování), ops toggles (správa provozních parametrů) a permission toggles (přístup podle rolí). V mobilních projektech jsou release toggles obzvláště užitečné: nová funkcionalita je skryta do data vydání, ale kód je již v trunk a prochází CI/CD.

// Feature Toggle v Androidu na Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

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

// Použití v kódu
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD v Trunk-Based Development: povinné postupy

Continuous Integration (CI) — nejdůležitější součást TBD. Každý push do trunk (nebo do dočasné větve před MR) spouští kompletní pipeline: sestavení, jednotkové testy, integrační testy, lintery, statickou analýzu, kontrolu pokrytí kódu. Pokud alespoň jedna fáze selže — autor změn opraví kód před dalším commitem. „Rozbitý trunk — zastavený vývoj" je hlavní pravidlo TBD.

Podle Jez Humble, Continuous Delivery, 2024, Trunk-Based Development vyžaduje CI pipeline, který se provede za 10–15 minut. Pokud sestavení trvá déle — vývojáři commit méně často, což ničí smysl TBD. V mobilních projektech Android a iOS může sestavení trvat 20–30 minut, což činí TBD méně pohodlným. V takových případech týmy používají Short-Lived Feature Branches (větve na 1 den) s okamžitým CI.

# GitHub Actions pro 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

Krátkožijící větve: pravidla práce v TBD

Krátkožijící větve (short-lived branches) — kompromis mezi čistým TBD (přímé commity do trunk) a Git Flow. Větev žije nejdéle 1–2 dny, obsahuje změny o 1–3 commitech a po review (ne více než 4 hodiny čekání) se sloučí do trunk. Pokud funkce vyžaduje více času — rozdělí se na podúkoly, každý s vlastní krátkožijící větví.

Podle TBD Documentation, 2024, pravidla krátkožijících větví: větev se vytváří z čerstvého trunk (ne staršího než 1 hodina), nesynchronizuje se s trunk pomocí merge/rebase (pokud uplynulo více než 4 hodiny — vytvoří se nová větev), MR/PR se vytváří ihned po prvním commitu (i když práce není dokončena — jako Draft).

Pre-tested commits: commity se zárukou

Pro Trunk-Based Development je důležitá technika pre-tested commits: vývojář před commitem spustí CI pipeline ve své větvi a teprve po zeleném statusu se commit dostane do trunk. V GitLab se to implementuje pomocí Merge Request pipelines s možností „Merge when pipeline succeeds". V GitHub — pomocí branch protection rules s Required status checks. To zaručuje, že trunk nikdy neobsahuje rozbitý kód.

• 1–2 dny — maximální životnost short-lived branch
• 1–3 commity — optimální velikost změn
• 4 hodiny — maximální doba čekání na code review
• Vytvoř MR ihned po prvním commitu, i ve statusu Draft

Branch by Abstraction: nahrazení kódu bez větvení

Branch by Abstraction — technika umožňující nahradit nebo výrazně změnit část systému bez vytváření dlouhožijící feature-větve. Místo větvení v Git vývojář vytvoří abstrakci (rozhraní), pod kterou pracuje jak stará, tak nová implementace. Postupně jsou všichni spotřebitelé převedeni na novou implementaci, načež je stará odstraněna.

Podle Branch by Abstraction, 2024, fáze Branch by Abstraction: 1) vytvořte abstrakci pro nahrazovanou komponentu, 2) implementujte novou verzi pod abstrakcí, 3) převeďte spotřebitele na novou implementaci pomocí konfigurace, 4) odstraňte starou implementaci. Všechny kroky se commit do trunk v malých dávkách, z nichž žádná nerozbíjí CI/CD.

TBD vs Git Flow: srovnání přístupů

Trunk-Based Development a Git Flow — dva protichůdné přístupy ke správě větví. Git Flow používá dlouhožijící větve a přísnou hierarchii, TBD — jednu větev a krátké integrační cykly. Volba mezi nimi závisí na velikosti týmu, frekvenci vydání a úrovni automatizace CI/CD.

Typické chyby při zavádění Trunk-Based Development

Chyby TBD jsou nejčastěji spojeny s nedostatečným CI/CD nebo slabou disciplínou commitů. První chyba — zavedení TBD bez CI, které se rozbije při prvním neúspěšném commitu. Pokud trunk nelze opravit do 15 minut — tým ztrácí důvěru v proces a vrací se k dlouhým větvím. Druhá — povolení dlouhožijících větví „výhradně pro tuto funkci", což ničí celý koncept.

Podle Paul Hammant, 2023, třetí chyba — špatná modularita kódu. Trunk-Based Development vyžaduje, aby byl kód rozdělen do nezávislých modulů. Pokud změna v jedné třídě rozbije tři další moduly — vývojáři nemohou commitovat v malých dávkách. Čtvrtá — ignorování feature toggles: pokus o commit nedokončeného kódu bez přepínače vede k rozbití trunk pro celý tým.

Trunk-Based Development v mobilním vývoji

Trunk-Based Development v mobilních projektech má specifika kvůli dlouhému sestavení (20–30 minut pro Android a iOS) a přísným požadavkům na kvalitu. Google a Spotify používají TBD v mobilním vývoji, aplikují short-lived branches s povinným průchodem CI před mergem. Feature toggles jsou spravovány pomocí Firebase Remote Config nebo LaunchDarkly.

Podle LaunchDarkly Docs, 2024, v mobilním vývoji TBD poskytuje výhodu: funkce jsou testovány v trunk spolu se zbytkem kódu před datem vydání, což snižuje riziko integračních problémů. Pokud CI pipeline trvá déle než 15 minut — optimální jsou short-lived branches na 1 den s automatickým CI při každém push. Pro Apple App Store a Google Play vyžaduje TBD nastavení staged rollouts prostřednictvím feature toggles.

Feature Flags jako služba: LaunchDarkly a Firebase

Pro správu feature toggles v TBD se používají platformy: LaunchDarkly (enterprise, plná funkčnost), Firebase Remote Config (zdarma pro malé projekty), Split.io (open-source). Poskytují: cílené zapínání funkcí podle procenta uživatelů, A/B testování, monitorování použití a automatické vypínání při chybách. V mobilních projektech je Firebase Remote Config nejoblíbenější volbou kvůli integraci s Firebase a bezplatnému limitu do 1000 uživatelů.