Trunk-Based Development — wat is het, principes en werken in één branch

Wat is Trunk-Based Development?

Trunk-Based Development (TBD) — een versiebeheermethodologie waarbij alle ontwikkelaars hun wijzigingen meerdere keren per dag integreren in één enkele hoofd branch (trunk, main of master). In tegenstelling tot Git Flow met zijn langlevende feature-branches, minimaliseert TBD de levensduur van branches tot enkele uren, zelden tot 1–2 dagen. Het hoofddoel is het vermijden van de „merge-hel" (merge hell), wanneer een grote functie na weken van ontwikkeling met trunk wordt samengevoegd.

Volgens Google Cloud DevOps, 2024, is Trunk-Based Development een van de belangrijkste praktijken van hoog presterende DevOps-teams. Uit het State of DevOps Report (Puppet, 2023) bleek dat teams die TBD gebruiken 30% sneller herstellen van storingen en 50% minder vaak kritieke defecten in productie tegenkomen. TBD is verplicht voor Continuous Deployment.

Trunk-Based Development betekent niet dat ontwikkelaars zonder controle direct naar trunk committen. In TBD worden kortlevende feature-branches gebruikt die na het maken van een MR en een snelle code review (binnen enkele uren) in trunk worden samengevoegd. Als de review langer dan een dag duurt — betekent dit dat de functie in kleinere delen moet worden opgesplitst.

State of DevOps Report: gegevens over TBD

Het jaarlijkse State of DevOps Report (Puppet/DORA) volgt de praktijken van hoog presterende teams. Sinds 2015 staat TBD in de top 3 van praktijken die correleren met een hoge leveringsfrequentie (deploy frequency) en een lage hersteltijd (MTTR). Teams die TBD toepassen, implementeren code 2–3 keer vaker en herstellen 30% sneller van storingen (DORA, 2023).

Feature Toggles: beheer van onvoltooide code zonder branches

Feature Toggles (functievlaggen, feature flags) — mechanisme om functionaliteit in en uit te schakelen zonder code te wijzigen. In TBD vervangen feature toggles feature-branches: de ontwikkelaar committed onvoltooide code naar trunk maar verbergt deze achter een voorwaardelijke vlag. Wanneer de functie klaar is om te worden getoond, wordt de vlag in de configuratie omgezet zonder opnieuw te implementeren.

Volgens Martin Fowler, 2024, worden feature toggles onderverdeeld in vier typen: release toggles (beheer van functiezichtbaarheid), experiment toggles (A/B-testen), ops toggles (beheer van operationele parameters) en permission toggles (toegang op basis van rollen). In mobiele projecten zijn release toggles bijzonder nuttig: nieuwe functionaliteit is verborgen tot de releasedatum, maar de code is al in trunk en doorloopt CI/CD.

// Feature Toggle in Android op Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

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

// Gebruik in code
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD in Trunk-Based Development: verplichte praktijken

Continuous Integration (CI) — de belangrijkste component van TBD. Elke push naar trunk (of naar een tijdelijke branch vóór MR) start een volledige pipeline: build, unittesten, integratietesten, linters, statische analyse, controle van codedekking. Als ten minste één fase faalt — herstelt de auteur van de wijzigingen de code vóór de volgende commit. „Gebroken trunk — gestopte ontwikkeling" is de hoofdregel van TBD.

Volgens Jez Humble, Continuous Delivery, 2024, vereist Trunk-Based Development een CI-pipeline die in 10–15 minuten wordt uitgevoerd. Als de build langer duurt — committen ontwikkelaars minder vaak, wat de betekenis van TBD tenietdoet. In mobiele Android- en iOS-projecten kan de build 20–30 minuten duren, wat TBD minder handig maakt. In dergelijke gevallen gebruiken teams Short-Lived Feature Branches (1-daagse branches) met onmiddellijke CI.

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

Kortlevende branches: werkregels in TBD

Kortlevende branches (short-lived branches) — compromis tussen pure TBD (directe commits naar trunk) en Git Flow. Een branch leeft niet langer dan 1–2 dagen, bevat wijzigingen voor 1–3 commits en wordt na review (niet meer dan 4 uur wachttijd) in trunk samengevoegd. Als een functie meer tijd nodig heeft — wordt deze verdeeld in subtaken, elk met een eigen kortlevende branch.

Volgens TBD Documentation, 2024, regels voor kortlevende branches: de branch wordt gemaakt vanaf een verse trunk (niet ouder dan 1 uur), wordt niet gesynchroniseerd met trunk via merge/rebase (als er meer dan 4 uur zijn verstreken — wordt een nieuwe branch gemaakt), MR/PR wordt onmiddellijk na de eerste commit gemaakt (zelfs als het werk niet is voltooid — als Draft).

Pre-tested commits: commits met garantie

Voor Trunk-Based Development is de techniek van pre-tested commits belangrijk: de ontwikkelaar start vóór de commit de CI-pipeline in zijn eigen branch en pas na een groene status komt de commit in trunk. In GitLab wordt dit geïmplementeerd via Merge Request pipelines met de optie „Merge when pipeline succeeds". In GitHub — via branch protection rules met Required status checks. Dit garandeert dat trunk nooit gebroken code bevat.

• 1–2 dagen — maximale levensduur van short-lived branch
• 1–3 commits — optimale omvang van wijzigingen
• 4 uur — maximale wachttijd voor code review
• Maak MR onmiddellijk na de eerste commit, zelfs in Draft-status

Branch by Abstraction: code vervangen zonder vertakking

Branch by Abstraction — techniek waarmee een deel van het systeem kan worden vervangen of aanzienlijk gewijzigd zonder een langlevende feature-branch te maken. In plaats van vertakking in Git maakt de ontwikkelaar een abstractie (interface) waaronder zowel de oude als de nieuwe implementatie werken. Geleidelijk worden alle consumenten overgezet naar de nieuwe implementatie, waarna de oude wordt verwijderd.

Volgens Branch by Abstraction, 2024, fasen van Branch by Abstraction: 1) maak een abstractie voor de te vervangen component, 2) implementeer de nieuwe versie onder de abstractie, 3) zet consumenten via configuratie over op de nieuwe implementatie, 4) verwijder de oude implementatie. Alle stappen worden in kleine porties naar trunk gecommit, waarvan geen enkele CI/CD breekt.

TBD vs Git Flow: vergelijking van benaderingen

Trunk-Based Development en Git Flow — twee tegenovergestelde benaderingen van branchbeheer. Git Flow gebruikt langlevende branches en een strikte hiërarchie, TBD — één branch en korte integratiecycli. De keuze tussen beide hangt af van de teamgrootte, releasefrequentie en het niveau van CI/CD-automatisering.

Typische fouten bij het implementeren van Trunk-Based Development

TBD-fouten houden meestal verband met onvoldoende CI/CD of een zwakke commit-discipline. De eerste fout — implementatie van TBD zonder CI, die bij de eerste mislukte commit stukgaat. Als trunk niet binnen 15 minuten kan worden gerepareerd — verliest het team het vertrouwen in het proces en keert terug naar lange branches. De tweede — het toestaan van langlevende branches „uitsluitend voor deze functie", wat het hele concept vernietigt.

Volgens Paul Hammant, 2023, de derde fout — slechte modulariteit van de code. Trunk-Based Development vereist dat de code in onafhankelijke modules is verdeeld. Als een wijziging in één klasse drie andere modules breekt — kunnen ontwikkelaars niet in kleine porties committen. De vierde — het negeren van feature toggles: een poging om onvoltooide code zonder vlag te committen leidt tot het breken van trunk voor het hele team.

Trunk-Based Development in mobiele ontwikkeling

Trunk-Based Development in mobiele projecten heeft bijzonderheden vanwege de lange buildtijd (20–30 minuten voor Android en iOS) en strikte kwaliteitseisen. Google en Spotify gebruiken TBD in mobiele ontwikkeling, met short-lived branches en verplichte CI-doorgang vóór merge. Feature toggles worden beheerd via Firebase Remote Config of LaunchDarkly.

Volgens LaunchDarkly Docs, 2024, biedt TBD in mobiele ontwikkeling een voordeel: functies worden samen met de rest van de code in trunk getest vóór de releasedatum, wat het risico op integratieproblemen vermindert. Als de CI-pipeline meer dan 15 minuten duurt — zijn short-lived branches van 1 dag met automatische CI bij elke push optimaal. Voor Apple App Store en Google Play vereist TBD het instellen van staged rollouts via feature toggles.

Feature Flags als service: LaunchDarkly en Firebase

Voor het beheer van feature toggles in TBD worden platforms gebruikt: LaunchDarkly (enterprise, volledige functionaliteit), Firebase Remote Config (gratis voor kleine projecten), Split.io (open-source). Zij bieden: gerichte inschakeling van functies op basis van gebruikerspercentage, A/B-testen, gebruiksmonitoring en automatische uitschakeling bij fouten. In mobiele projecten is Firebase Remote Config de populairste keuze vanwege de integratie met Firebase en de gratis drempel tot 1000 gebruikers.