Trunk-Based Development — cos'è, principi e lavoro in un singolo branch

Cos'è Trunk-Based Development?

Trunk-Based Development (TBD) è una metodologia di gestione delle versioni in cui tutti gli sviluppatori integrano le loro modifiche in un unico branch principale (trunk, main o master) più volte al giorno. A differenza di Git Flow con i suoi branch di funzionalità di lunga durata, TBD minimizza la durata dei branch a poche ore, raramente a 1–2 giorni. L'obiettivo principale è evitare l'“inferno del merge” (merge hell), quando una grande funzionalità viene unita al trunk dopo settimane di sviluppo.

Secondo Google Cloud DevOps, 2024, Trunk-Based Development è una delle pratiche chiave dei team DevOps ad alte prestazioni. State of DevOps Report (Puppet, 2023) ha mostrato che i team che usano TBD si riprendono il 30% più velocemente dai guasti e affrontano il 50% in meno di difetti critici in produzione. TBD è obbligatorio per Continuous Deployment.

Trunk-Based Development non significa che gli sviluppatori facciano commit direttamente nel trunk senza revisione. In TBD si utilizzano branch di funzionalità di breve durata che, dopo la creazione di un MR e una rapida revisione del codice (entro poche ore), vengono uniti al trunk. Se la revisione richiede più di un giorno, la funzionalità deve essere scomposta in parti più piccole.

State of DevOps Report: dati su TBD

Il State of DevOps Report annuale (Puppet/DORA) tiene traccia delle pratiche dei team ad alte prestazioni. Dal 2015, TBD è tra le prime 3 pratiche correlate a un'elevata frequenza di deploy (deploy frequency) e un basso tempo di recupero (MTTR). I team che praticano TBD distribuiscono codice 2–3 volte più spesso e si riprendono il 30% più velocemente dai guasti (DORA, 2023).

Feature Toggles: gestione del codice incompleto senza branch

Feature Toggles (flag di funzionalità, feature flags) sono un meccanismo per attivare e disattivare funzionalità senza modificare il codice. In TBD, i feature toggles sostituiscono i branch di funzionalità: lo sviluppatore invia codice incompleto nel trunk ma lo nasconde dietro un flag condizionale. Quando la funzionalità è pronta per essere mostrata, il flag viene commutato nella configurazione senza ridistribuzione.

Secondo Martin Fowler, 2024, i feature toggles si dividono in quattro tipi: release toggles (gestione della visibilità delle funzionalità), experiment toggles (test A/B), ops toggles (gestione dei parametri operativi) e permission toggles (accesso basato sui ruoli). Nei progetti mobile, i release toggles sono particolarmente utili: la nuova funzionalità è nascosta fino alla data di rilascio, ma il codice è già nel trunk e passa attraverso CI/CD.

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

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

// Uso nel codice
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD in Trunk-Based Development: pratiche obbligatorie

Continuous Integration (CI) è il componente più importante di TBD. Ogni push nel trunk (o in un branch temporaneo prima del MR) attiva una pipeline completa: build, test unitari, test di integrazione, linter, analisi statica, verifica della copertura del codice. Se almeno una fase fallisce, l'autore corregge il codice prima del commit successivo. “Trunk rotto — sviluppo fermo” è la regola principale di TBD.

Secondo Jez Humble, Continuous Delivery, 2024, Trunk-Based Development richiede una pipeline CI che venga completata in 10–15 minuti. Se la build richiede più tempo, gli sviluppatori fanno commit meno frequentemente, il che distrugge il significato di TBD. Nei progetti mobile, le build Android e iOS possono richiedere 20–30 minuti, rendendo TBD meno conveniente. In questi casi, i team utilizzano Short-Lived Feature Branches (branch di 1 giorno) con CI immediato.

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

Branch di breve durata: regole di lavoro in TBD

I branch di breve durata (short-lived branches) sono un compromesso tra TBD puro (commit diretti nel trunk) e Git Flow. Un branch vive non più di 1–2 giorni, contiene modifiche di 1–3 commit e dopo la revisione (non più di 4 ore di attesa) viene unito al trunk. Se una funzionalità richiede più tempo, viene suddivisa in sotto-attività, ciascuna con il proprio branch di breve durata.

Secondo TBD Documentation, 2024, le regole dei branch di breve durata: il branch viene creato da un trunk fresco (non più vecchio di 1 ora), non viene sincronizzato con il trunk tramite merge/rebase (se sono passate più di 4 ore, viene creato un nuovo branch), il MR/PR viene creato immediatamente dopo il primo commit (anche se il lavoro non è completo — come Draft).

Pre-tested Commits: commit con garanzia

Per Trunk-Based Development, la tecnica dei pre-tested commits è importante: lo sviluppatore esegue la pipeline CI nel proprio branch prima di fare commit, e solo dopo uno stato verde il commit raggiunge il trunk. In GitLab, questo è implementato tramite Merge Request pipelines con l'opzione “Merge when pipeline succeeds”. In GitHub — tramite branch protection rules con Required status checks. Questo garantisce che il trunk non contenga mai codice rotto.

• 1–2 giorni — durata massima di un short-lived branch
• 1–3 commit — dimensione ottimale delle modifiche
• 4 ore — tempo massimo di attesa per la revisione del codice
• Crea il MR immediatamente dopo il primo commit, anche in stato Draft

Branch by Abstraction: sostituzione del codice senza ramificazione

Branch by Abstraction è una tecnica che consente di sostituire o modificare significativamente una parte del sistema senza creare un branch di funzionalità di lunga durata. Invece di ramificare in Git, lo sviluppatore crea un'astrazione (interfaccia) sotto la quale funzionano sia l'implementazione vecchia che quella nuova. Gradualmente, tutti i consumatori vengono migrati alla nuova implementazione, dopo di che quella vecchia viene rimossa.

Secondo Branch by Abstraction, 2024, le fasi di Branch by Abstraction: 1) creare un'astrazione per il componente da sostituire, 2) implementare la nuova versione sotto l'astrazione, 3) commutare i consumatori alla nuova implementazione tramite configurazione, 4) rimuovere l'implementazione vecchia. Tutti i passaggi vengono impegnati nel trunk in piccole porzioni, ciascuna delle quali non rompe CI/CD.

TBD vs Git Flow: confronto degli approcci

Trunk-Based Development e Git Flow sono due approcci opposti alla gestione dei branch. Git Flow utilizza branch di lunga durata e una gerarchia rigida, TBD utilizza un unico branch e cicli di integrazione brevi. La scelta tra di essi dipende dalla dimensione del team, dalla frequenza dei rilasci e dal livello di automazione CI/CD.

Errori tipici nell'implementazione di Trunk-Based Development

Gli errori di TBD sono spesso legati a CI/CD insufficiente o a una debole disciplina dei commit. Il primo errore è implementare TBD senza CI, che si rompe al primo commit fallito. Se il trunk non può essere riparato entro 15 minuti, il team perde fiducia nel processo e torna ai branch lunghi. Il secondo errore è permettere branch di lunga durata “solo per questa funzionalità”, il che distrugge l'intero concetto.

Secondo Paul Hammant, 2023, il terzo errore è la scarsa modularità del codice. Trunk-Based Development richiede che il codice sia suddiviso in moduli indipendenti. Se una modifica in una classe rompe altri tre moduli, gli sviluppatori non possono fare commit in piccole porzioni. Il quarto errore è ignorare i feature toggles: tentare di inviare codice incompleto senza un flag rompe il trunk per l'intero team.

Trunk-Based Development nello sviluppo mobile

Trunk-Based Development nei progetti mobile ha peculiarità a causa dei lunghi tempi di build (20–30 minuti per Android e iOS) e dei rigorosi requisiti di qualità. Google e Spotify utilizzano TBD nello sviluppo mobile, applicando branch di breve durata con CI obbligatorio prima del merge. I feature toggles sono gestiti tramite Firebase Remote Config o LaunchDarkly.

Secondo LaunchDarkly Docs, 2024, nello sviluppo mobile, TBD offre un vantaggio: le funzionalità vengono testate nel trunk insieme al resto del codice prima della data di rilascio, riducendo il rischio di problemi di integrazione. Se la pipeline CI richiede più di 15 minuti, i branch di breve durata di 1 giorno con CI automatico a ogni push sono ottimali. Per Apple App Store e Google Play, TBD richiede la configurazione di rollout graduali tramite feature toggles.

Feature Flags come servizio: LaunchDarkly e Firebase

Per la gestione dei feature toggles in TBD vengono utilizzate piattaforme: LaunchDarkly (enterprise, completo), Firebase Remote Config (gratuito per progetti piccoli), Split.io (open-source). Forniscono: attivazione mirata delle funzionalità per percentuale di utenti, test A/B, monitoraggio dell'utilizzo e disattivazione automatica in caso di errori. Nei progetti mobile, Firebase Remote Config è la scelta più popolare grazie all'integrazione con Firebase e alla soglia gratuita fino a 1000 utenti.