Trunk-Based Development — was es ist, Prinzipien und Arbeiten in einem Branch

Was ist Trunk-Based Development?

Trunk-Based Development (TBD) ist eine Versionsverwaltungsmethode, bei der alle Entwickler ihre Änderungen mehrmals täglich in einen einzigen Hauptbranch (trunk, main oder master) integrieren. Im Gegensatz zu Git Flow mit seinen langlebigen Feature-Branches minimiert TBD die Lebensdauer von Branches auf wenige Stunden, selten auf 1–2 Tage. Das Hauptziel ist es, die „merge hell“ zu vermeiden, wenn eine große Funktion nach wochenlanger Entwicklung in den trunk integriert wird.

Laut Google Cloud DevOps, 2024 ist Trunk-Based Development eine der wichtigsten Praktiken von leistungsstarken DevOps-Teams. Der State of DevOps Report (Puppet, 2023) zeigte, dass Teams, die TBD verwenden, sich 30% schneller von Ausfällen erholen und 50% seltener mit kritischen Fehlern in der Produktion konfrontiert werden. TBD ist für Continuous Deployment obligatorisch.

Trunk-Based Development bedeutet nicht, dass Entwickler ohne Überprüfung direkt in den trunk committen. In TBD werden kurzlebige Feature-Branches verwendet, die nach Erstellung eines MR und schnellem Code-Review (innerhalb weniger Stunden) in den trunk integriert werden. Wenn ein Review länger als einen Tag dauert, muss die Funktion in kleinere Teile zerlegt werden.

State of DevOps Report: Daten über TBD

Der jährliche State of DevOps Report (Puppet/DORA) verfolgt die Praktiken von leistungsstarken Teams. Seit 2015 gehört TBD zu den Top-3-Praktiken, die mit hoher Bereitstellungsfrequenz (deploy frequency) und niedriger Wiederherstellungszeit (MTTR) korrelieren. Teams, die TBD praktizieren, stellen 2–3 Mal häufiger Code bereit und erholen sich 30% schneller von Ausfällen (DORA, 2023).

Feature Toggles: Verwaltung von unvollständigem Code ohne Branches

Feature Toggles (Funktionsflags) sind ein Mechanismus zum Aktivieren und Deaktivieren von Funktionen ohne Codeänderung. In TBD ersetzen Feature Toggles die Feature-Branches: der Entwickler committed unvollständigen Code in den trunk, verbirgt ihn jedoch hinter einem konditionalen Flag. Wenn die Funktion bereit zur Anzeige ist, wird das Flag in der Konfiguration ohne erneute Bereitstellung umgeschaltet.

Laut Martin Fowler, 2024 werden Feature Toggles in vier Typen unterteilt: Release Toggles (Verwaltung der Funktionssichtbarkeit), Experiment Toggles (A/B-Tests), Ops Toggles (Verwaltung betrieblicher Parameter) und Permission Toggles (rollenbasierter Zugriff). In mobilen Projekten sind Release Toggles besonders nützlich: neue Funktionalität bleibt bis zum Veröffentlichungsdatum verborgen, aber der Code befindet sich bereits im trunk und durchläuft CI/CD.

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

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

// Verwendung im Code
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD in Trunk-Based Development: obligatorische Praktiken

Continuous Integration (CI) ist die wichtigste Komponente von TBD. Jeder Push in den trunk (oder in einen temporären Branch vor dem MR) löst eine vollständige Pipeline aus: Build, Komponententests, Integrationstests, Linter, statische Analyse, Codeabdeckungsprüfung. Wenn mindestens eine Stufe fehlschlägt, korrigiert der Autor den Code vor dem nächsten Commit. „Caputter trunk — Entwicklung gestoppt“ ist die Hauptregel von TBD.

Laut Jez Humble, Continuous Delivery, 2024 erfordert Trunk-Based Development eine CI-Pipeline, die in 10–15 Minuten abgeschlossen ist. Wenn der Build länger dauert, committen Entwickler seltener, was den Sinn von TBD zerstört. In mobilen Projekten können Android- und iOS-Builds 20–30 Minuten dauern, was TBD weniger praktikabel macht. In solchen Fällen verwenden Teams Short-Lived Feature Branches (1-Tages-Branches) mit sofortiger CI.

# GitHub Actions für 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

Kurzlebige Branches: Arbeitsregeln in TBD

Kurzlebige Branches (short-lived branches) sind ein Kompromiss zwischen reinem TBD (direkte Commits in den trunk) und Git Flow. Ein Branch lebt nicht länger als 1–2 Tage, enthält Änderungen von 1–3 Commits und wird nach dem Review (maximal 4 Stunden Wartezeit) in den trunk integriert. Wenn eine Funktion mehr Zeit benötigt, wird sie in Teilaufgaben aufgeteilt, jede mit ihrem eigenen kurzlebigen Branch.

Laut TBD Documentation, 2024 lauten die Regeln für kurzlebige Branches: der Branch wird von einem frischen trunk (nicht älter als 1 Stunde) erstellt, nicht mit dem trunk über merge/rebase synchronisiert (wenn mehr als 4 Stunden vergangen sind, wird ein neuer Branch erstellt), MR/PR wird unmittelbar nach dem ersten Commit erstellt (auch wenn die Arbeit nicht abgeschlossen ist — als Draft).

Pre-tested Commits: Commits mit Garantie

Für Trunk-Based Development ist die Technik der pre-tested Commits wichtig: der Entwickler führt die CI-Pipeline in seinem Branch vor dem Commit aus, und erst nach grünem Status gelangt der Commit in den trunk. In GitLab wird dies durch Merge-Request-Pipelines mit der Option „Merge when pipeline succeeds“ implementiert. In GitHub — durch Branch-Protection-Regeln mit Required status checks. Dies stellt sicher, dass der trunk niemals defekten Code enthält.

• 1–2 Tage — maximale Lebensdauer eines short-lived branch
• 1–3 Commits — optimale Änderungsgröße
• 4 Stunden — maximale Wartezeit für Code-Review
• Erstelle MR sofort nach dem ersten Commit, auch im Draft-Status

Branch by Abstraction: Code-Ersatz ohne Verzweigung

Branch by Abstraction ist eine Technik, die es ermöglicht, einen Teil eines Systems zu ersetzen oder wesentlich zu ändern, ohne einen langlebigen Feature-Branch zu erstellen. Anstatt in Git zu verzweigen, erstellt der Entwickler eine Abstraktion (Schnittstelle), unter der sowohl die alte als auch die neue Implementierung arbeiten. Nach und nach werden alle Konsumenten auf die neue Implementierung umgestellt, wonach die alte entfernt wird.

Laut Branch by Abstraction, 2024 sind die Phasen von Branch by Abstraction: 1) Erstellen einer Abstraktion für die zu ersetzende Komponente, 2) Implementieren der neuen Version unter der Abstraktion, 3) Umschalten der Konsumenten auf die neue Implementierung über Konfiguration, 4) Entfernen der alten Implementierung. Alle Schritte werden in kleinen Portionen in den trunk committed, die jeweils CI/CD nicht brechen.

TBD vs Git Flow: Vergleich der Ansätze

Trunk-Based Development und Git Flow sind zwei gegensätzliche Ansätze zur Branch-Verwaltung. Git Flow verwendet langlebige Branches und eine strenge Hierarchie, TBD verwendet einen einzigen Branch und kurze Integrationszyklen. Die Wahl zwischen ihnen hängt von der Teamgröße, der Release-Häufigkeit und dem Grad der CI/CD-Automatisierung ab.

Typische Fehler bei der Einführung von Trunk-Based Development

TBD-Fehler stehen meist im Zusammenhang mit unzureichendem CI/CD oder schwacher Commit-Disziplin. Der erste Fehler ist die Einführung von TBD ohne CI, das beim ersten fehlgeschlagenen Commit scheitert. Wenn der trunk nicht innerhalb von 15 Minuten repariert werden kann, verliert das Team das Vertrauen in den Prozess und kehrt zu langen Branches zurück. Der zweite Fehler ist die Erlaubnis langlebiger Branches „nur für diese Funktion“, was das gesamte Konzept zerstört.

Laut Paul Hammant, 2023 ist der dritte Fehler eine schlechte Code-Modularität. Trunk-Based Development erfordert, dass der Code in unabhängige Module aufgeteilt ist. Wenn eine Änderung in einer Klasse drei andere Module bricht, können Entwickler nicht in kleinen Portionen committen. Der vierte Fehler ist das Ignorieren von Feature Toggles: der Versuch, unvollständigen Code ohne Flag zu committen, bricht den trunk für das gesamte Team.

Trunk-Based Development in der mobilen Entwicklung

Trunk-Based Development hat in mobilen Projekten Besonderheiten aufgrund langer Build-Zeiten (20–30 Minuten für Android und iOS) und strenger Qualitätsanforderungen. Google und Spotify verwenden TBD in der mobilen Entwicklung mit kurzlebigen Branches und obligatorischer CI vor dem Merge. Feature Toggles werden über Firebase Remote Config oder LaunchDarkly verwaltet.

Laut LaunchDarkly Docs, 2024 bietet TBD in der mobilen Entwicklung einen Vorteil: Funktionen werden vor dem Veröffentlichungsdatum im trunk zusammen mit dem restlichen Code getestet, was das Risiko von Integrationsproblemen reduziert. Wenn die CI-Pipeline mehr als 15 Minuten dauert, sind 1-Tages-Short-Lived-Branches mit automatischer CI bei jedem Push optimal. Für Apple App Store und Google Play erfordert TBD die Einrichtung von gestaffelten Rollouts über Feature Toggles.

Feature Flags als Dienst: LaunchDarkly und Firebase

Zur Verwaltung von Feature Toggles in TBD werden Plattformen verwendet: LaunchDarkly (Enterprise, voll ausgestattet), Firebase Remote Config (kostenlos für kleine Projekte), Split.io (Open-Source). Sie bieten: gezielte Funktionsaktivierung nach Benutzerprozentsatz, A/B-Tests, Nutzungsüberwachung und automatische Deaktivierung bei Fehlern. In mobilen Projekten ist Firebase Remote Config aufgrund der Integration mit Firebase und des kostenlosen Kontingents von bis zu 1000 Benutzern die beliebteste Wahl.