# Cos e il trunk based development: guida pratica 2026 URL: https://codebasechat.com/it/journal/cos-e-il-trunk-based-development Type: blog Locale: it Published: 2026-09-22 Updated: 2026-09-22 --- > Il trunk based development elimina i branch longevi imponendo integrazioni giornaliere su main. Feature flag, CI continua e commit piccoli: i tre pilastri che lo rendono sostenibile. ## Cos e il trunk based development Il trunk based development è una strategia di branching in cui ogni sviluppatore integra il codice su un unico ramo condiviso, solitamente chiamato `main` o `trunk`, almeno una volta al giorno. Non esistono feature branch longevi. Il codice è sempre in stato pronto per la produzione. Se una funzionalità non è ancora completata, un feature flag la nasconde agli utenti: non un branch che la isola dal team. Questa è la sintesi. Il dettaglio riguarda il perché il tuo workflow attuale potrebbe generare più rischio di quanto pensi. ## Perché i branch longevi diventano un debito La maggior parte dei team impara il controllo di versione attraverso i feature branch: un branch per ticket, merge dopo la review. Sembra organizzato. Quando un branch vive più di 24 ore, ogni commit che i tuoi colleghi fanno su main è un conflitto futuro che non hai ancora visto. In un team di otto ingegneri, ognuno con un branch da due settimane, non stai gestendo un'integrazione. Stai amministrando otto mondi paralleli che divergono un po' ogni giorno. Il giorno del merge non è un'attività: è una trattativa. La ricerca DORA, il più grande studio longitudinale sulle performance di delivery del software condotto su migliaia di team, traccia qui una linea netta: i branch che vivono più di 24 ore sono un segnale predittivo di frequenza di deployment più bassa e tassi di failure più alti. I team elite integrano più volte al giorno. Gli altri fanno merge quando la feature è "pronta", il che spesso significa mai in modo pulito. Il costo nascosto non è il conflitto di merge in sé. È il context-switching necessario per risolverlo tre settimane dopo che il codice è stato scritto. Nessuno ricorda più qual era l'intento originale. ## Come funziona davvero il trunk based development La meccanica è diretta. Fai pull di main. Fai una modifica piccola e coerente. Esegui la test suite. Fai push su main. Tutto questo prima di pranzo. Per un singolo sviluppatore su un repo piccolo, è già così che funziona. Per un team di venti su un monorepo da 300K LOC, richiede tre pratiche che lavorano insieme: **Branch di breve durata (opzionali ma comuni)**: Alcuni team permettono branch fino a due giorni prima di forzare il merge. Questo conserva la cultura della code review senza creare divergenze su più settimane. Il branch è un veicolo di review, non un meccanismo di isolamento. **Continuous integration su ogni push**: Ogni commit su main innesca una build completa e la test suite. Se si rompe, si rompe in pochi minuti, non dopo che un feature branch da due settimane arriva venerdì alle 16. **Feature flag per il lavoro incompleto**: Le funzionalità non finite vengono deployate in produzione dietro un flag. Gli utenti non vedono nulla. Il team integra tutto. Questo è il pezzo che la maggior parte dei team salta, ed è per questo che il primo esperimento con il TBD fallisce. Nessuna di queste pratiche è esclusiva del trunk based development. La differenza è che il TBD le rende tutte obbligatorie invece che opzionali. ## Feature flag: il meccanismo che rende possibile il TBD ![Mani di uno sviluppatore su una tastiera con una dashboard di feature flag visibile sullo schermo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) Un feature flag è un condizionale nel codice che viene valutato a runtime. Quando un flag è disattivato, il nuovo percorso di codice non viene eseguito. Quando è attivo, per un utente specifico, una percentuale del traffico o tutta la base utenti, viene eseguito. Sembra banale. Le implicazioni non lo sono: puoi separare il deployment dal rilascio. Il codice va in produzione continuamente. Le funzionalità vengono lanciate quando sono pronte, oppure non vengono lanciate del tutto se il rollout va storto e devi disattivarle in dieci secondi invece di fare rollback su tre settimane di commit. La configurazione minima richiede tre cose: un modo per definire i flag, un modo per valutarli a runtime, e un modo per modificarli senza fare redeploy. Un file di configurazione JSON piatto funziona per un team di tre persone. Un servizio dedicato di feature management giustifica la propria complessità intorno ai dieci ingegneri, o quando i flag iniziano ad aver bisogno di regole di targeting come "attivo per gli utenti nella coorte beta in Germania". Una cosa da monitorare: il debito dei flag. I flag che non vengono mai rimossi dopo che la feature è deployata diventano spaghetti di condizionali. Un team che fa TBD correttamente rimuove ogni flag entro uno sprint dal momento in cui la feature è completamente in produzione. Tratta i flag come ponteggi temporanei, non come configurazione permanente. ## TBD vs Gitflow: un confronto diretto per il 2026 Gitflow è stato progettato nel 2010 per software in scatola rilasciato su cicli trimestrali. Modella i rilasci come branch longevi. Per i team che fanno deployment ogni giorno o ogni ora, quel modello non si adatta più. Ecco come appare il confronto per un team che fa CI/CD: **Durata del branch**: Gitflow lavora su giorni o settimane. Il TBD lavora su ore, con un massimo di 1-2 giorni. **Conflitti di merge**: Gitflow produce conflitti frequenti e ad alta intensità. Il TBD produce conflitti rari e a bassa intensità perché i gap di integrazione sono ore, non settimane. **Frequenza di deployment**: Gitflow lega il deployment a un release branch. Il TBD disaccoppia completamente deployment e rilascio. **Meccanismo di rollback**: Gitflow fa rollback revertendo il merge di un branch. Il TBD fa rollback disattivando un feature flag. **Complessità di onboarding**: Gitflow richiede di capire le convenzioni develop/main/hotfix. Il TBD ha un solo branch: main. **Investimento CI richiesto**: Gitflow è basso (i branch assorbono il rischio). Il TBD è alto (main deve rimanere verde in ogni momento). Gitflow non è sbagliato in ogni contesto. Se distribuisci un'app mobile sull'App Store e non puoi fare push di hotfix in pochi minuti, un modello a release branch ha senso. Se gestisci un SaaS dove controlli i deployment, la struttura di branching aggiuntiva è overhead che aggiunge costo di coordinamento senza aggiungere sicurezza. ## Cosa dicono le metriche DORA sulle strategie di branching ![Due ingegneri che fanno pair programming e code review su uno schermo condiviso](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) La [ricerca DORA State of DevOps](https://dora.dev/research/) monitora le performance di delivery del software dal 2014. Due risultati dai dati sono direttamente rilevanti qui. Primo: il trunk based development è una delle 24 capability che predicono le performance di delivery nel modello DORA. Si trova nel cluster "continuous delivery", il che significa che DORA lo tratta come una pratica infrastrutturale, non una preferenza del team. Secondo: i team elite fanno deployment più volte al giorno. I low performer fanno deployment una volta alla settimana o al mese. I branch longevi e l'integrazione poco frequente compaiono all'estremità più lenta di quella distribuzione su più anni di dati. Quello che la ricerca non afferma: che il TBD causi performance elite. I team che adottano il TBD con successo tendono già ad avere test automatizzati, una CI pipeline funzionante, e l'abitudine dei commit piccoli. Il trunk based development fa emergere immediatamente queste lacune se mancano. Un team senza CI e con il 40% di test flakiness non beneficerà del passaggio al TBD. Romperà main più spesso, e basta. ## Dove il trunk based development non ha senso Tre scenari in cui il TBD crea più problemi di quanti ne risolve: **Ambienti fortemente regolamentati con gate di approvazione pre-rilascio**: Se ogni rilascio richiede un sign-off di compliance prima di andare in produzione, il deployment continuo è bloccato comunque. Il modello di branching diventa secondario. **Test suite non adeguate**: Il TBD richiede una CI pipeline veloce e affidabile. Se le build richiedono 45 minuti e hanno il 20% di flakiness, gli sviluppatori raggrupperanno i commit per evitare di aspettare. Il vincolo è l'infrastruttura di test, non la convenzione di branching. **Team molto grandi con ownership del codice non uniforme**: In team con 50+ persone dove ogni squad possiede un servizio distinto, il TBD funziona bene a livello di servizio. Applicarlo su un monorepo condiviso dove tutti toccano tutto richiede convenzioni di linting rigorose e regole di ownership della CI per mantenere main pulito. In tutti e tre i casi, la soluzione non è una strategia di branching diversa. La soluzione è il problema infrastrutturale sottostante. Il TBD rende semplicemente quel problema visibile più velocemente. ## Come migrare senza bloccare le delivery La migrazione che la maggior parte dei team sbaglia: annunciano il TBD, eliminano la convenzione del feature branch, e vedono main rompersi nella prima settimana. Un percorso più sicuro: - **Mantieni i branch esistenti, aggiungi una regola sulla durata**: Nessun branch vive più di 3 giorni. Questo forza la pressione dell'integrazione frequente senza spegnere le luci. - **Strumenta prima la CI**: Prima che i merge diventino veloci, devono essere sicuri. Assicurati che la test suite sia verde, giri in meno di 15 minuti e blocchi il branch main in caso di fallimento. - **Scegli una feature da proteggere con un flag**: Costruisci il muscolo del flag management prima di averne bisogno per ogni feature incompleta. - **Riduci la durata del branch settimana per settimana**: Da 3 giorni a 2 giorni a 1 giorno in sei settimane. Monitora la frequenza dei conflitti di merge come indicatore anticipatore. Quando scende, il modello funziona. - **Abbandona la vecchia convenzione solo quando quella nuova funziona**: Le convenzioni Gitflow rimangono in vigore per tutto ciò che è fuori dal pilota. Fare girare entrambi i modelli per 6-8 settimane è accettabile. ## L'abitudine che determina se il TBD durerà ![Un ingegnere che monitora dashboard CI/CD con indicatori di stato deployment verdi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) Il trunk based development non fallisce perché i team non sanno fare merge su main. Fallisce perché gli sviluppatori non hanno l'abitudine di suddividere il lavoro in pezzi abbastanza piccoli da completare in un giorno. Il cambiamento sottostante non è tecnico. È il modo in cui il lavoro viene definito in fase di pianificazione. Una user story che dice "implementa il nuovo flusso di pagamento" è un branch da due settimane in attesa di essere creato. Una storia che dice "aggiungi il route handler e restituisci un 501 dietro il flag `payment-v2`" è un commit da mezza giornata. Questo richiede il coinvolgimento del PM e un backlog hygiene che la maggior parte dei team non ha ancora costruito. Il cambio di strategia di branching richiede un giorno per essere annunciato. La disciplina di scoping richiede sei mesi per essere costruita. Se il tuo team fa già deploy di software funzionante in produzione ogni giorno, il TBD formalizza quello che già fai. Se fai deploy ogni due settimane con un big-bang merge alla fine, il TBD non sarà comodo finché le abitudini di delivery sottostanti non cambieranno. I team che rimangono con il TBD sono quelli che hanno investito in tre cose prima del cambio: una CI pipeline sotto i 15 minuti, un servizio di feature flag funzionante, e cerimonie di sprint che producono storie abbastanza piccole da essere chiuse in un giorno. ## Gli strumenti che aiutano i team a lavorare in TBD Fare trunk based development a livello di team significa più allineamento sincrono: standup rapidi per intercettare la deriva da integrazione, convenzioni documentate per flag e regole CI, e chiamate per pair-review sui percorsi critici. ## FAQ ### Cosa distingue il trunk based development da un workflow con feature branch? Nel TBD ogni sviluppatore integra su main almeno una volta al giorno. Non esistono branch che vivono più di 1-2 giorni. Le feature non pronte vengono protette da feature flag, non isolate in un branch separato. ### Il trunk based development è adatto a un team piccolo, di 2-3 persone? Sì, ed è il contesto più semplice in cui adottarlo. Con pochi sviluppatori l'overhead di coordinamento è minimo e la CI pipeline più facile da mantenere sotto i 15 minuti. ### È necessario un servizio di feature flag dedicato per iniziare con il TBD? No. Un file di configurazione JSON o un sistema semplice di environment variable funziona per team piccoli. Un servizio dedicato diventa necessario quando i flag richiedono regole di targeting per segmenti di utenti specifici o quando il ciclo di vita dei flag diventa un problema in sé. ### Qual è la differenza tra trunk based development e continuous integration? La CI è la pratica di verificare ogni commit con una build automatizzata. Il TBD è la strategia di branching che stabilisce dove quei commit vanno. Sono complementari: il TBD senza CI funzionante rende main instabile. ### Il TBD è compatibile con pull request e code review? Sì. Molti team usano branch di breve durata (massimo 1-2 giorni) come veicoli di review prima del merge. La differenza rispetto a Gitflow è la durata: il branch esiste per la review, non per l'isolamento della feature. ### Come si gestisce un rollback in trunk based development? Disattivando il feature flag della funzionalità problematica, in pochi secondi. Questo è uno dei vantaggi concreti rispetto al rollback via git revert su branch longevi, che richiede di identificare esattamente quale commit revertire. ### Perché le metriche DORA collegano il TBD alle performance elevate? DORA identifica il TBD come una delle 24 capability che predicono performance di software delivery elevata. I team che integrano frequentemente tendono già ad avere test automatizzati e CI affidabile, le stesse pratiche che abilitano deployment frequenti e bassi tassi di failure.