Trunk based development cos'e: tutto quello che devi sapere
Riassunto
Il trunk-based development prevede che tutti i developer facciano commit su un unico branch condiviso (main) almeno una volta al giorno. I branch vivono ore, non settimane. I feature flag nascondono le funzionalità incomplete. Il codebase rimane sempre rilasciabile. Il report DORA 2021 mostra che i team con prestazioni elevate hanno 2,3 volte più probabilità di usare questo approccio. Richiede CI/CD solida, test automatici e disciplina del team.
Se ti stai chiedendo trunk based development cos'e, la risposta è immediata: ogni sviluppatore del team fa commit su un unico branch condiviso chiamato trunk -- di solito main -- almeno una volta al giorno. Niente branch a vita lunga. Niente hotfix-v2-backup-finale abbandonato per tre settimane. I branch corti vivono per ore, fanno merge veloce e vengono eliminati. Il codebase rimane continuamente rilasciabile. Google fa girare 35.000 sviluppatori in questo modo. Ecco come funziona, quando ha senso e quando no.
Il problema del "report_v2_FINALE_usa_questo.xlsx" -- ma nel codice
Se hai mai aperto una cartella condivisa e trovato report_v1.xlsx, report_v2_FINALE.xlsx e report_USA_QUESTO_modifiche_greg.xlsx uno accanto all'altro, capisci già il problema che il trunk-based development cerca di risolvere.
Quella stessa situazione si ripete nei codebase quando i team usano branch di funzionalità a vita lunga. Qualcuno inizia una feature nella prima settimana. Il resto del team continua a spedire codice. Alla terza settimana, quel branch è dozzine di commit indietro rispetto a main. Fare il merge diventa un progetto del weekend che nessuno vuole gestire. I conflitti si accumulano. Il developer che ha scritto il codice ha dimenticato perché esiste la metà di esso. Questo si chiama "merge hell".
Gitflow -- l'alternativa più insegnata -- cerca di risolvere il problema con una struttura formale: branch separati per feature, release e hotfix, ognuno con una durata di vita definita. La struttura sembra pulita sulla carta. In pratica, i branch si accumulano come versioni di spreadsheet su una cartella condivisa e il giorno dell'integrazione diventa la settimana dell'integrazione.
Il trunk-based development prende la posizione opposta: smettila di accumulare debito di integrazione. Fai commit su main. Oggi.
Tutti su main. Ogni giorno. Questo è il modello.
La regola fondamentale è semplice: tutti i developer inviano le modifiche al trunk condiviso almeno una volta ogni 24 ore. Nessuna eccezione per "non ho ancora finito" -- fai commit di quello che hai e ti assicuri che quello che hai non rompa la build.
Sembra allarmante finché non capisci i meccanismi che lo rendono sicuro:
Branch a vita breve: puoi ancora usare branch, ma vivono per ore, non per settimane. Un branch che dura più di due giorni è un segnale di allerta che vale la pena indagare.
Test automatici su ogni commit: la tua pipeline CI esegue la suite di test immediatamente. Se qualcosa si rompe, lo sai in minuti, non alla fine di uno sprint.
Feature flag: le funzionalità a metà costruzione rimangono nascoste dietro un toggle finché non sono pronte per il rilascio. Gli utenti non vedono mai il lavoro incompleto, anche se è già nel codice in produzione.
Il risultato è un codebase sempre rilasciabile -- non "rilasciabile dopo che abbiamo fatto il merge del branch di feature e eseguito QA per una settimana", ma rilasciabile adesso se necessario. Questa è la promessa fondamentale.
Branch a vita breve: si misurano in ore, non in settimane
Nel trunk-based development non ti è vietato di usare branch. Ti è vietato di usare branch lunghi.
Un branch che apri alle 9 di mattina, su cui lavori tutta la mattina, ottieni una code review dopo pranzo e fai merge su main prima delle 17 è esattamente il tipo giusto. Dà ai tuoi colleghi la possibilità di rivedere il lavoro prima che atterri sul trunk. È abbastanza piccolo da capire in una singola lettura. I conflitti, se ci sono, si risolvono in minuti.
Un branch che vive tre settimane mentre un developer costruisce un intero sistema di autenticazione in isolamento è il problema. Quando arriva il momento del merge, il team passa più tempo a risolvere conflitti di quanti ne abbia passati a costruire la funzionalità.
La soglia pratica che usa la maggior parte dei team trunk-based: se un branch non ha fatto merge entro due giorni, qualcosa deve cambiare. O la feature è troppo grande e va suddivisa in pezzi più piccoli, o ha bisogno di un feature flag per far atterrare il lavoro parziale in modo sicuro.
Scomporre il lavoro in pezzi più piccoli è la disciplina fondamentale che il trunk-based development sviluppa concretamente. Invece di "costruire l'intera dashboard", spedisci "aggiungi il data layer", poi "aggiungi il primo grafico", poi "collega i filtri". Ogni pezzo fa merge sul trunk, viene testato e viene spedito in modo indipendente. La funzionalità completa emerge in modo incrementale attraverso diversi commit.
Sembra più lento. In pratica è più veloce, perché trovi i problemi mentre il contesto è ancora fresco e la superficie è ancora piccola.
Feature flag: come spedire lavoro incompleto senza rompere nulla
I feature flag (chiamati anche feature toggle) sono il meccanismo che rende il trunk-based development praticabile quando una feature non può essere completata in un unico branch a vita breve.
L'idea è semplice: racchiudi la nuova funzionalità in un condizionale che si attiva solo quando un flag specifico è abilitato.
if (featureFlags.nuovaDashboardReport) {
renderNuovaDashboard();
} else {
renderVecchiaDashboard();
}Il nuovo codice viene distribuito in produzione. Semplicemente non viene eseguito per gli utenti finché non abiliti il toggle. Questo significa:
I developer possono fare commit di lavori in corso sul trunk senza influire su nessuno
Il QA può testare la feature in produzione abilitando il flag per un utente o ambiente specifico
Un lancio diventa un cambio di configurazione, non un evento di deployment
Se qualcosa si rompe, disattivi il flag senza rollback né branch di hotfix
L'infrastruttura di feature flag scala da una semplice variabile d'ambiente controllata all'avvio fino a piattaforme di feature flag dedicate. Per un team che inizia, un file di configurazione o una variabile per ambiente è sufficiente. Il punto è la capacità, non la complessità degli strumenti.
Quando il trunk-based development non è la scelta giusta
Vale la pena dirlo chiaramente: il trunk-based development non è universalmente migliore. Si adatta a contesti specifici.
Evitalo se:
La tua pipeline CI/CD non è pronta. Il trunk-based development senza test automatici su ogni commit non è una strategia di branching -- è un codebase rotto che si deteriora velocemente. L'infrastruttura di test deve essere in atto prima che il modello di branching possa funzionare. Senza CI, ogni commit sul trunk è una scommessa.
Il team non può fare commit frequenti per natura. I team distribuiti dove i contributori lavorano in modo asincrono su fusi orari diversi, o i progetti open-source dove i contributori inviano batch infrequenti, faranno fatica con la cadenza di commit giornalieri. Il modello presuppone che tutti i developer siano attivi e raggiungibili entro la stessa finestra lavorativa.
Sei in un ambiente regolamentato con finestre di rilascio obbligatorie. Alcune industrie richiedono approvazione esterna, lunghi cicli di QA e audit trail formali per branch di release. I branch di release strutturati di Gitflow si adattano meglio a quel tipo di workflow, dove ogni versione deve essere validata e firmata prima di arrivare in produzione.
La disciplina del team non è ancora pronta. Il trunk-based development richiede che ogni commit su main passi tutti i test o venga corretto immediatamente. Se il tuo team tollera build rotte anche per poche ore, il trunk condiviso diventa il problema condiviso di tutti.
Gitflow è una scelta ragionevole per team con cicli di rilascio trimestrali, più feature concorrenti sviluppate da squad separati, o requisiti di conformità che richiedono isolamento a livello di branch. La domanda è l'adattamento onesto al contesto, non quale approccio vinca in linea di principio.
Come passare da Gitflow al trunk-based development senza crisi
Se il tuo team è su Gitflow e vuole provare il trunk-based development, la migrazione non deve essere un taglio netto.
Inizia smettendo di creare nuovi branch a vita lunga. Le feature iniziate dopo la decisione ottengono branch a vita breve. Le feature già in corso su branch lunghi finiscono secondo il vecchio modello. I due approcci coesistono temporaneamente, senza forzare una conversione immediata di tutto il lavoro in corso.
Prima di fare commit di lavoro incompiuto sul trunk, hai bisogno di feature flag in atto. Impostare anche solo un sistema di feature flag di base è il prerequisito per tutto il resto. Senza di esso, il trunk-based development significa spedire interfacce incomplete agli utenti in produzione.
Poi applica la CI obbligatoria sul branch main: i test automatici vengono eseguiti su ogni push, i test che falliscono bloccano il merge e nessuno fa merge senza una build verde. Questa è la parte non negoziabile.
Infine, definisci la regola dei due giorni esplicitamente: qualsiasi branch più vecchio di due giorni ottiene una conversazione su cosa fare. Rompi la feature in pezzi più piccoli, aggiungi un flag, o spedisci quello che è già completo. Rendilo visibile nel tuo processo di pull request, così il team vede il segnale prima che diventi un problema.
L'aggiustamento scomodo che la maggior parte dei team affronta: accettare che "parzialmente completo" è una cosa valida da committare, purché sia nascosto dietro un flag e non rompa i test esistenti.
Cosa dicono i dati del report DORA sulla velocità di rilascio
I report DevOps Research and Assessment (DORA) sono la cosa più vicina che lo sviluppo software ha alla ricerca empirica su larga scala sulle pratiche dei team. Il report DORA 2021 ha rilevato che i team con prestazioni elevate hanno 2,3 volte più probabilità di usare il trunk-based development rispetto ai team con prestazioni inferiori.
I top performer nel framework DORA fanno deployment più volte al giorno, con lead time dal commit alla produzione misurati in ore piuttosto che settimane. Il trunk-based development si correla costantemente con questi risultati.
L'avvertenza importante: la correlazione non è causalità. I team ad alte prestazioni adottano il trunk-based development perché hanno già investito nella disciplina sottostante -- test automatici, infrastruttura CI/CD solida, engineer che scrivono modifiche piccole e mirate. Queste fondamenta vengono prima. Il trunk-based development è il modello di branching che si adatta a quel contesto, non la cosa che lo crea.
Biscuit lo capisce in fretta: un buon retriever non cerca di portare tre palline allo stesso tempo. Un commit, una review, un merge. Good boy.
Vale la pena cambiare approccio?
Se il tuo team passa tempo significativo ogni sprint sui merge conflict, ritarda i rilasci perché "il branch di feature non è pronto", o ha branch aperti così a lungo che nessuno ricorda più a cosa servivano -- il trunk-based development vale una valutazione seria.
La cadenza di commit giornalieri è impegnativa. L'infrastruttura di feature flag richiede configurazione iniziale. Il cambiamento culturale richiede qualche settimana per consolidarsi. Ma il risultato -- un codebase sempre rilasciabile, merge conflict misurati in righe e non in file, e rilasci che sono di routine piuttosto che crisi -- è un miglioramento significativo nel modo in cui il team lavora.
Inizia in piccolo: un team, uno sprint, CI in esecuzione su ogni push, feature flag in atto. Osserva cosa cambia in quattro settimane.