Trunk-based development

Trunk-based development significa che il branch principale, di solito main, è il centro vivo del progetto. I branch laterali esistono, ma restano corti. Il lavoro viene integrato spesso e il branch principale deve rimanere sempre in uno stato rilasciabile.

Non è “tutti pushano a caso su main”. È un workflow disciplinato basato su integrazione continua, test rapidi, branch piccoli e feature flag.

Perché questa lezione conta

Più tardi integri, più costoso diventa integrare. Branch lunghi accumulano conflitti, assunzioni vecchie e sorprese. Trunk-based riduce questo debito forzando il team a spezzare il lavoro in cambiamenti piccoli.

È particolarmente adatto a prodotti web, SaaS e team che rilasciano spesso.

Obiettivo operativo

Alla fine della lezione devi saper valutare se trunk-based è adatto al tuo team e quali prerequisiti servono per non trasformarlo in caos.

Principi

1. main è sempre verde;
2. branch di lavoro brevi;
3. CI obbligatoria;
4. feature grandi spezzate;
5. feature flag per codice non pronto;
6. rollback o revert rapidi;
7. review leggera ma frequente.

Il punto centrale è ridurre la dimensione dell’integrazione.

Cosa misurare

Per capire se stai davvero lavorando in trunk-based, misura pochi indicatori:

età media dei branch
dimensione media PR
tempo tra apertura e merge
tempo di feedback CI
numero di revert su main

Se i branch durano dieci giorni e le PR arrivano a migliaia di righe, il workflow è trunk-based solo nel nome.

Feature flag

Senza feature flag, trunk-based spinge a tenere branch aperti finché la feature non è completa. Con feature flag puoi mergiare codice non visibile:

Codice presente in main
Feature disattivata per utenti
Attivazione graduale via configurazione

Questo separa merge da rilascio. È una differenza fondamentale.

Branch corti

Esempio di ciclo:

git switch main
git pull --ff-only
git switch -c fix/login-timeout
# modifica piccola
git add -p
git commit -m "fix(auth): gestisci timeout login"
git push -u origin fix/login-timeout
# PR, CI, review, merge

Il branch vive ore o pochi giorni, non settimane.

Prerequisiti

Trunk-based funziona se hai:

1. test automatici affidabili;
2. build rapida;
3. branch protection;
4. deploy reversibile;
5. feature flag o toggles;
6. cultura di PR piccole.

Senza questi, trunk-based può diventare “main rotto spesso”.

Quando non basta

Può non essere ideale se:

1. devi supportare più versioni rilasciate;
2. hai release fisiche o regolamentate;
3. la CI è lenta e fragile;
4. il team non sa spezzare lavoro grande;
5. non esistono feature flag.

In questi casi, un workflow con release branch può essere più realistico.

Laboratorio guidato

Analizza il tuo progetto:

1. tempo medio di vita dei branch;
2. tempo medio review PR;
3. frequenza merge su main;
4. tempo CI;
5. possibilità di feature flag;
6. frequenza release.

Poi scegli una regola sperimentale per una settimana:

Nessun branch feature oltre 2 giorni.
PR sotto 300 righe di diff quando possibile.
Main sempre verde.

Output atteso

Una decisione documentata:

Adottiamo trunk-based / non lo adottiamo ancora.
Prerequisiti mancanti:
Regole branch:
Regole CI:
Regole feature flag:

Errori comuni

Confondere trunk-based con assenza di review. Puoi avere PR piccole e veloci.

Mergiare codice non testato. Main deve restare rilasciabile.

Branch corti solo a parole. Serve misurare età dei branch.

Feature flag senza pulizia. I flag vecchi diventano debito.

Checklist di verifica

• main è protetto e verde;
• i branch sono brevi;
• le feature incomplete possono restare spente;
• CI è abbastanza rapida;
• il team sa fare rollback o revert.

Collegamenti

• Modulo: Workflow di team — lezione 26 del corso.
• Confronta con GitHub Flow e GitFlow nelle prossime lezioni.