Trunk-Based Development — vad är det, principer och arbete i en gren

Vad är Trunk-Based Development?

Trunk-Based Development (TBD) — en versionshanteringsmetod där alla utvecklare integrerar sina ändringar i en enda huvudgren (trunk, main eller master) flera gånger om dagen. Till skillnad från Git Flow med dess långlivade feature-grenar, minimerar TBD grenarnas livslängd till några timmar, sällan till 1–2 dagar. Huvudmålet är att undvika "merge-helvetet" (merge hell), när en stor funktion slås samman med trunk efter veckors utveckling.

Enligt Google Cloud DevOps, 2024, är Trunk-Based Development en av de viktigaste praxiserna för högpresterande DevOps-team. Forskningen State of DevOps Report (Puppet, 2023) visade att team som använder TBD återhämtar sig 30% snabbare från fel och stöter på 50% mindre ofta på kritiska defekter i produktion. TBD är obligatoriskt för Continuous Deployment.

Trunk-Based Development betyder inte att utvecklare committar direkt till trunk utan verifiering. I TBD används kortlivade feature-grenar som efter skapandet av MR och snabb kodgranskning (inom några timmar) slås samman i trunk. Om granskningen tar längre tid än en dag — betyder det att funktionen måste delas upp i mindre delar.

State of DevOps Report: data om TBD

Den årliga State of DevOps Report (Puppet/DORA) följer praxis hos högpresterande team. Sedan 2015 har TBD funnits bland de tre främsta praxiserna som korrelerar med hög leveransfrekvens (deploy frequency) och låg återhämtningstid (MTTR). Team som tillämpar TBD distribuerar kod 2–3 gånger oftare och återhämtar sig 30% snabbare från fel (DORA, 2023).

Feature Toggles: hantering av oavslutad kod utan grenar

Feature Toggles (funktionsflaggor, feature flags) — mekanism för att aktivera och inaktivera funktionalitet utan att ändra kod. I TBD ersätter feature toggles feature-grenar: utvecklaren committar oavslutad kod till trunk men döljer den bakom en villkorlig flagga. När funktionen är redo att visas, växlas flaggan i konfigurationen utan omdistribution.

Enligt Martin Fowler, 2024, delas feature toggles in i fyra typer: release toggles (hantering av funktionssynlighet), experiment toggles (A/B-testning), ops toggles (hantering av operativa parametrar) och permission toggles (åtkomst baserat på roller). I mobilprojekt är release toggles särskilt användbara: ny funktionalitet är gömd till releasedatumet, men koden är redan i trunk och passerar CI/CD.

// Feature Toggle i Android på Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

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

// Användning i kod
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD i Trunk-Based Development: obligatorisk praxis

Continuous Integration (CI) — den viktigaste komponenten i TBD. Varje push till trunk (eller till en temporär gren före MR) startar en fullständig pipeline: bygge, enhetstester, integrationstester, linters, statisk analys, kontroll av kodtäckning. Om minst en fas misslyckas — reparerar författaren av ändringarna koden före nästa commit. "Trasig trunk — stoppad utveckling" är huvudregeln för TBD.

Enligt Jez Humble, Continuous Delivery, 2024, kräver Trunk-Based Development en CI-pipeline som körs på 10–15 minuter. Om bygget tar längre tid — committar utvecklare mer sällan, vilket förstör meningen med TBD. I mobilprojekt för Android och iOS kan bygget ta 20–30 minuter, vilket gör TBD mindre bekvämt. I sådana fall använder team Short-Lived Feature Branches (1-dagars grenar) med omedelbar 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

Kortlivade grenar: arbetsregler i TBD

Kortlivade grenar (short-lived branches) — kompromiss mellan ren TBD (direkta commits till trunk) och Git Flow. En gren lever inte längre än 1–2 dagar, innehåller ändringar för 1–3 commits och efter granskning (inte mer än 4 timmars väntan) slås samman i trunk. Om en funktion kräver mer tid — delas den upp i deluppgifter, var och en med sin egen kortlivade gren.

Enligt TBD Documentation, 2024, regler för kortlivade grenar: grenen skapas från färsk trunk (inte äldre än 1 timme), synkroniseras inte med trunk via merge/rebase (om mer än 4 timmar har passerat — skapas en ny gren), MR/PR skapas omedelbart efter första commit (även om arbetet inte är slutfört — som Draft).

Pre-tested commits: commits med garanti

För Trunk-Based Development är tekniken pre-tested commits viktig: utvecklaren startar före commit CI-pipelinen i sin egen gren och först efter grön status kommer commit in i trunk. I GitLab implementeras detta genom Merge Request pipelines med alternativet "Merge when pipeline succeeds". I GitHub — genom branch protection rules med Required status checks. Detta garanterar att trunk aldrig innehåller trasig kod.

• 1–2 dagar — maximal livslängd för short-lived branch
• 1–3 commits — optimal storlek på ändringar
• 4 timmar — maximal väntetid för kodgranskning
• Skapa MR omedelbart efter första commit, även i Draft-status

Branch by Abstraction: kodbyte utan förgrening

Branch by Abstraction — teknik som gör det möjligt att ersätta eller väsentligt ändra en del av systemet utan att skapa en långlivad feature-gren. Istället för förgrening i Git skapar utvecklaren en abstraktion (gränssnitt) under vilken både den gamla och nya implementeringen fungerar. Gradvis flyttas alla konsumenter till den nya implementeringen, varefter den gamla tas bort.

Enligt Branch by Abstraction, 2024, stegen i Branch by Abstraction: 1) skapa en abstraktion för komponenten som ska ersättas, 2) implementera den nya versionen under abstraktionen, 3) flytta konsumenterna till den nya implementeringen genom konfiguration, 4) ta bort den gamla implementeringen. Alla steg committas till trunk i små portioner, ingen av dem bryter CI/CD.

TBD vs Git Flow: jämförelse av tillvägagångssätt

Trunk-Based Development och Git Flow — två motsatta tillvägagångssätt för grenhantering. Git Flow använder långlivade grenar och strikt hierarki, TBD — en gren och korta integrationscykler. Valet mellan dem beror på teamstorlek, utgivningsfrekvens och nivån på CI/CD-automatisering.

Vanliga misstag vid implementering av Trunk-Based Development

TBD-misstag är oftast relaterade till otillräcklig CI/CD eller svag commit-disciplin. Det första misstaget — implementering av TBD utan CI, som går sönder vid första misslyckade commit. Om trunk inte kan repareras inom 15 minuter — förlorar teamet förtroendet för processen och återgår till långa grenar. Det andra — att tillåta långlivade grenar "endast för denna funktion", vilket förstör hela konceptet.

Enligt Paul Hammant, 2023, det tredje misstaget — dålig modularitet i koden. Trunk-Based Development kräver att koden är uppdelad i oberoende moduler. Om en ändring i en klass bryter tre andra moduler — kan utvecklarna inte committa i små portioner. Det fjärde — att ignorera feature toggles: ett försök att committa oavslutad kod utan flagga leder till att trunk går sönder för hela teamet.

Trunk-Based Development i mobil utveckling

Trunk-Based Development i mobilprojekt har särdrag på grund av lång byggtid (20–30 minuter för Android och iOS) och strikta kvalitetskrav. Google och Spotify använder TBD i mobil utveckling och tillämpar short-lived branches med obligatorisk CI-passage före merge. Feature toggles hanteras via Firebase Remote Config eller LaunchDarkly.

Enligt LaunchDarkly Docs, 2024, i mobil utveckling ger TBD en fördel: funktioner testas i trunk tillsammans med resten av koden före releasedatumet, vilket minskar risken för integrationsproblem. Om CI-pipelinen tar mer än 15 minuter — är short-lived branches på 1 dag med automatisk CI vid varje push optimala. För Apple App Store och Google Play kräver TBD konfigurering av staged rollouts via feature toggles.

Feature Flags som tjänst: LaunchDarkly och Firebase

För hantering av feature toggles i TBD används plattformar: LaunchDarkly (enterprise, full funktionalitet), Firebase Remote Config (gratis för små projekt), Split.io (open-source). De erbjuder: riktad aktivering av funktioner efter användarprocent, A/B-testning, användningsövervakning och automatisk avaktivering vid fel. I mobilprojekt är Firebase Remote Config det populäraste valet på grund av integration med Firebase och gratiströskeln upp till 1000 användare.