Trunk-based development vs GitFlow per rilasci settimanali

Perché il rilascio settimanale si complica con il modello di branching sbagliato

Il rilascio settimanale sembra semplice finché non arriva la settimana in cui lo perdi. La build è "quasi pronta" giovedì, il QA trova problemi venerdì sera, e il lunedì diventa pulizia invece che un inizio ordinato.

Un fattore principale è il modello di branching. Decide quando le modifiche si incontrano, dove avviene l'integrazione e quanto rapidamente puoi recuperare quando qualcosa si rompe. Se l'integrazione è spostata alla fine della settimana, paghi il prezzo con conflitti di merge, bug a sorpresa e ambienti di test instabili.

Quando il workflow lavora contro di te, spesso si avverte così:

• I merge richiedono più tempo del lavoro che li ha causati.
• Il QA testa la combinazione sbagliata di cambiamenti perché i branch si discostano.
• I rilasci diventano una negoziazione invece di una routine.
• Gli hotfix scatenano panico perché nessuno è sicuro di cosa altro verrà rilasciato.
• Le persone smettono di fidarsi del QA e chiedono eccezioni.

Il branching influenza anche la stabilità del QA. Se il QA continua a oscillare tra percorsi di codice solo parzialmente integrati, diventa un bersaglio in movimento. Anche i tester più esperti non possono dare risposte chiare quando il sistema sotto test cambia ogni poche ore, o quando un merge tardivo sostituisce silenziosamente ciò che avevano testato il giorno prima.

Per questo motivo i team confrontano spesso trunk-based development e GitFlow quando passano a un ritmo di rilascio settimanale. La domanda utile non è quale sia più popolare, ma quale riduce il dolore dei merge, mantiene i rilasci prevedibili, rende gli hotfix sicuri e rapidi e mantiene il QA significativo.

Assumi un team piccolo o medio, un repository condiviso e CI che gira a ogni push. Forse rilasci una web app e un'API. O magari parte del team costruisce in modo visuale con una piattaforma come AppMaster mantenendo comunque codice generato e deploy come qualsiasi team prodotto.

Se il tuo processo crea grandi merge alla fine della settimana, la cadenza settimanale continuerà a slittare. Se favorisce integrazione piccola e frequente, i rilasci settimanali inizieranno a sembrare noiosi (nel senso migliore).

Trunk-based development e GitFlow in parole semplici

Entrambi gli approcci sono solo regole su come usare i branch affinché il lavoro passi da "in corso" a "rilasciato" senza caos. La differenza reale è quanti branch a lunga vita tieni e quanto tempo il lavoro resta separato prima di incontrare il codice degli altri.

• Trunk-based mantiene quasi tutto vicino a main.
• GitFlow mantiene corsie separate per lavoro in corso e stabilizzazione del rilascio.

Trunk-based development (in parole semplici)

Trunk-based development tratta main (la trunk) come il centro. Le persone lavorano in branch a vita breve (ore fino a uno o due giorni), fanno merge frequentemente e mantengono main in uno stato rilasciabile.

Se qualcosa non è pronto, la soluzione è tenerlo abbastanza piccolo da finirlo velocemente oppure nasconderlo dietro un feature flag così può essere rilasciato senza essere visibile.

GitFlow (in parole semplici)

GitFlow tipicamente usa un branch develop a lunga vita dove arriva prima il lavoro delle feature, più branch feature che partono da develop. Vicino al rilascio si crea un branch release/* per stabilizzare e testare. Se la produzione si rompe, si crea un branch hotfix/* (spesso da main) e lo si merge indietro.

Questo modello ottimizza la separazione: il lavoro in corso può continuare su develop mentre il branch di release viene testato e sistemato.

Molto dolore nasce da fraintendimenti comuni:

• Trattare il trunk-based come "niente branch" (in realtà si usano branch, sono solo a vita breve).
• Usare GitFlow ma non creare mai un vero branch di release, così develop diventa un'area di staging instabile.
• Lasciare feature branch per settimane, il che trasforma qualsiasi modello in una fonte di problemi di merge.
• Confondere "rilasciabile" con "tutto è finito" invece che con "sicuro da distribuire".

Attrito dei merge: cosa lo provoca davvero

I conflitti di merge di solito nascono da due fonti: branch che vivono troppo a lungo e più persone che cambiano le stesse aree senza coordinazione.

La differenza pratica più grande tra trunk-based e GitFlow è quanto tempo il lavoro resta separato prima di incontrarsi con quello degli altri.

Con trunk-based, le modifiche arrivano spesso sulla linea principale. Le pull request sono più piccole, le diff sono più piccole e i conflitti emergono prima mentre il contesto è fresco. I conflitti capitano ancora, ma sono più facili da risolvere perché si sta riconciliando qualche riga, non due settimane di deriva. Il compromesso è la disciplina: mantenere le build verdi, fare cambi incrementali e trattare main come il prodotto.

Con GitFlow, il lavoro delle feature può restare inattivo più a lungo senza influenzare gli sviluppatori giorno per giorno. Il costo emerge dopo come eventi di merge più grandi: feature→develop, develop→release/*, e release/*→main. Ogni merge è un incontro più grande di cambiamenti, quindi i conflitti sono più probabili e più difficili da sbrogliare. Per rilasci settimanali, quei grandi merge tendono ad arrivare proprio quando il team vuole testare.

Anche il carico di code review si sposta. Trunk-based di solito significa più review, ma ognuna è più veloce da comprendere. GitFlow spesso porta review meno numerose ma più pesanti, oltre al tempo extra di review durante i merge di release quando tutti sono stanchi.

Per ridurre l'attrito dei merge in entrambi i modelli:

• Mantieni le PR piccole e focalizzate (un obiettivo alla volta).
• Concorda la responsabilità per aree rischiose (migrazioni, config condivisa, UI core).
• Integra le modifiche upstream quotidianamente per non driftare.
• Se un file è costantemente "caldo", lavorateci in coppia invece di competere in parallelo.

Se i conflitti sono continui, di solito è un segno che stai integrando troppo tardi, non che Git sia il problema.

Prevedibilità del rilascio per una cadenza settimanale

Prevedibilità significa tre cose: sai quando il rilascio esce, sai cosa contiene e sai quali controlli devono passare prima della pubblicazione. I team di solito perdono i rilasci settimanali perché mescolano decisioni di scope con fix dell'ultimo minuto.

Nel trunk-based, i rilasci settimanali restano prevedibili quando main resta verde. Unisci piccoli cambiamenti spesso e controlla lo scope con feature flag invece che con branch a lunga vita. Questo mantiene il treno settimanale in movimento anche se una feature non è finita. Il codice può atterrare, ma il comportamento visibile resta spento finché non è pronto.

I gate di qualità sono spesso più semplici perché c'è un solo posto da validare:

• I test automatici devono passare su main.
• Il QA testa un candidato stabile, non quello che è arrivato l'ultima ora.
• I passi di rollout e rollback sono documentati.
• C'è un chiaro cutoff di rilascio (anche se arrivano altri commit).

In GitFlow, la prevedibilità viene dal branch di release che funge da zona di freeze. Scegli un cutoff, crea release/* e permetti solo le modifiche necessarie per spedire. Quel confine aiuta, ma aggiunge coordinazione perché le correzioni di solito vanno applicate in più posti (release e develop).

Il lavoro non finito è gestito diversamente:

• Trunk-based: unisci le parti sicure e tieni il resto dietro flag.
• GitFlow: mantieni il lavoro non finito in develop ed escludilo dal branch di release.

Esempio: se i miglioramenti al checkout sono a metà mercoledì, il trunk-based può unire i refactor sicuri e tenere la nuova UI nascosta. GitFlow di solito lo lascia in develop, spedisce senza di esso e lo completa per il prossimo rilascio settimanale.

Flusso hotfix: il percorso più veloce e sicuro verso produzione

Un hotfix non è lavoro normale. Serve velocità, basso rischio e un percorso che riporti la modifica dove il team lavora così non si corregge lo stesso bug due volte.

Inizia con una domanda: quale codice sta effettivamente girando in produzione ora? Se non lo sai in pochi secondi, gli hotfix diventano congetture.

Hotfix con trunk-based development

Gli hotfix in trunk-based possono sembrare più semplici perché main è considerato la fonte di verità.

Un flusso comune:

• Crea un branch a vita breve dal commit di produzione (spesso main).
• Fai la correzione più piccola possibile (aggiungi un test se puoi).
• Unisci di nuovo su main rapidamente.
• Distribuisci da main e tagga il rilascio.

Poiché il team si integra frequentemente in main, l'hotfix diventa naturalmente parte del prossimo rilascio settimanale. Il rischio principale è rompere la regola "main è rilasciabile" lasciando lavoro a metà in main. I feature flag aiutano, ma tienili spenti per default e verifica l'hotfix senza abilitare feature non correlate.

Hotfix con GitFlow

In GitFlow, gli hotfix di solito partono da main (produzione) e poi devono essere uniti di nuovo in develop così la correzione non va persa.

Un flusso sicuro:

• Branch hotfix/* da main al tag di produzione.
• Correggi e rilascia (dal branch hotfix o dopo il merge in main).
• Unisci l'hotfix in main e anche in develop.
• Se esiste un release/*, uniscilo anche lì.

Il fallimento più comune è dimenticare una di queste merge. Una settimana dopo, il bug "torna" perché develop non ha mai ricevuto la patch.

Una regola semplice previene la maggior parte di questo: un hotfix non è finito finché non è stato unito in tutti i branch a lunga vita che rilasceranno di nuovo.

Come mantenere stabili gli ambienti QA (senza bloccare il team)

Il rilascio settimanale si sfalda quando "QA" significa "qualunque cosa sia deployata adesso." Nomina i tuoi ambienti e assegna a ciascuno un compito: dev per feedback rapido, QA per i test del team, staging per i controlli di rilascio, prod per i clienti. Se non riesci a spiegare lo scopo di un ambiente in una frase, la gente lo userà in modo scorretto.

Regole che evitano bersagli in movimento

Un QA stabile dipende meno dal modello di branching e più da cosa deployi.

Nel lavoro trunk-based, non deployare commit casuali su QA. Distribuisci un candidato bloccato (build taggata, numero di build o un branch release-candidate a vita breve) che passa gli stessi controlli ogni volta. Il QA ha qualcosa di fisso da testare, anche mentre lo sviluppo continua su main.

In GitFlow, il QA di solito segue il branch di release. La trappola è lasciare che il branch di release cambi dopo che il QA è partito. Una volta che il QA inizia, tratta il branch di release come un contratto: accetta solo fix approvati e solo con un processo chiaro.

Un piccolo insieme di regole mantiene prevedibile ogni approccio:

• Deploya su QA solo da build che passano.
• Blocca la versione deployata (tag, numero build o head del branch di release) e annunciala.
• Limita le modifiche in QA a bug fix, non a nuove feature.
• Resetta i dati di test con cadenza e documenta cosa viene cancellato.
• Tieni la configurazione come codice (variabili e template) per ridurre la deriva degli ambienti.

Se il tuo team usa AppMaster per parte della build, applica lo stesso principio: rigenera e distribuisci una specifica build per il QA, non un set di modifiche in continuo cambiamento.

Quando più team condividono il QA

Un ambiente QA condiviso diventa un collo di bottiglia quando due team hanno bisogno di versioni diverse. Se non puoi permetterti ambienti QA separati, aggiungi una regola leggera di prenotazione: un team è a turno proprietario del QA per una finestra temporale e gli altri usano dev o staging. Anche i feature flag aiutano perché il lavoro incompleto può essere deployato senza essere visibile ai tester.

Esempio: il Team A sta validando il candidato di rilascio settimanale, quindi il QA resta bloccato sulla build 1842 fino al sign-off. Il Team B può continuare a unire fix, ma quei cambiamenti aspettano il prossimo candidato invece di cambiare ciò che il QA sta testando a metà ciclo.

Passo dopo passo: scegli un workflow che il team possa seguire ogni settimana

Scrivi cosa significa per voi "rilascio settimanale". Scegli un giorno e un orario per il rilascio, decidi quale livello di rischio è accettabile (per esempio, "nessun bug P1 conosciuto") e annota dimensione del team e fusi orari. Questo impedisce che i dibattiti sui branch diventino discussioni sulle priorità.

Scegli un modello base e impegnati a seguirlo per un mese. Non mescolare i modelli il primo giorno. Mescolare di solito aggiunge regole senza ridurre le sorprese.

Un workflow settimanale semplice da adattare:

• Tieni i branch a vita corta (ore fino a 1-2 giorni) e fai merge almeno quotidianamente.
• Aggiungi protezioni: CI veloce, revisione breve obbligatoria e una piccola suite di test automatici che rilevino rotture reali.
• Decidi come controllare lo scope: feature flag, un branch di release a vita breve vicino alla fine della settimana, o tag per il commit esatto di rilascio.
• Definisci i passi per gli hotfix: chi può avviarli, quali controlli servono e come la correzione ritorna sulla linea principale.
• Mantieni il QA stabile: decidi cosa segue il QA (branch di release o candidato bloccato) e non cambiarlo a metà test a meno che non si riavvii il ciclo.

Scrivi il workflow minimo in una pagina. Deve essere abbastanza breve perché un nuovo collega lo segua senza riunioni. Questo è ancora più importante se parte del team lavora in modo visuale (per esempio, in AppMaster) e parte in codice, perché i passaggi falliscono quando le regole vivono solo nella testa di qualcuno.

Esempio: un rilascio settimanale realistico in entrambi i modelli

Immagina un team prodotto di 6 persone che rilascia ogni venerdì. Due tester QA condividono un ambiente staging, quindi se lo staging è instabile i test si fermano per tutti.

Una settimana intensa con GitFlow

Lunedì: tre sviluppatori finiscono feature e aprono PR verso develop. Il QA comincia a testare lo staging costruito da develop.

Mercoledì: il team taglia release/1.8 per proteggere il rilascio di venerdì. Nuovo lavoro continua a entrare in develop, ma il QA ora si concentra sulla build di release.

Giovedì pomeriggio: appare un bug tardivo. La correzione atterra prima in release/1.8 così il QA può ritestare rapidamente. Poi qualcuno unisce quella correzione in develop, ed è qui che spesso avvengono errori.

Ritmo tipico:

• Lun-Mar: feature merge in develop, lo staging cambia spesso.
• Mer: crea release/1.8, lo staging passa a build di release.
• Gio: fix in release/1.8, poi merge in develop.
• Ven: merge release/1.8 in main, tag e deploy.

La stessa settimana con trunk-based development

La settimana è strutturata attorno a merge piccoli e frequenti su main. Le feature sono dietro flag così il lavoro incompleto può essere unito senza impattare gli utenti.

Da lunedì a giovedì: gli sviluppatori uniscono piccole modifiche quotidianamente. Il QA testa un candidato bloccato.

Martedì: appare un problema in produzione. L'hotfix è un branch corto da main, viene unito subito dopo la review e promosso in produzione. Poiché main è la fonte di verità, non c'è un passo di back-merge extra.

In entrambi i casi, il team ha bisogno di regole chiare di promozione:

• Lo staging esegue l'ultimo candidato bloccato, non ogni nuovo commit.
• Il QA richiede un nuovo candidato quando è pronto, non automaticamente.
• Solo i fix per il rilascio di venerdì possono cambiare il candidato.
• Tutto il resto aspetta dietro flag o resta fuori dal candidato.

Errori comuni che generano churn e QA instabile

La maggior parte dei team non fallisce perché ha scelto il modello "sbagliato". Fallisce perché le abitudini quotidiane non corrispondono al modello, così il QA diventa rumoroso e i rilasci sembrano casuali.

Un problema comune è lasciare i branch per giorni perché "non è pronto." Il codice si discosta da main, i conflitti si accumulano e il QA finisce per testare un mix di lavoro vecchio e nuovo che nessuno riesce a riprodurre.

Un altro è usare GitFlow senza un vero freeze. Un branch di release dovrebbe stabilizzare, ma i team continuano a infilare "solo un'altra" modifica. Questo trasforma il branch di release in una seconda linea principale e nessuno sa cosa il QA sta firmando.

Il QA diventa instabile anche quando è trattato come un ambiente dove buttare build a metà. Se ogni commit va su QA senza regole, i tester passano il tempo a inseguire bersagli in movimento invece di validare un rilascio.

Gli errori che causano più churn:

• Feature branch a lunga vita che vengono uniti tardi e rompono lavoro non correlato.
• Branch di release che accettano ancora nuove feature.
• Nessun percorso di promozione chiaro, così la build che il QA ha testato non è quella che viene rilasciata.
• Hotfix fatti di fretta e mai uniti ovunque.
• Ambienti senza proprietario, senza scopo e senza piano di reset.

Mantieni un set di regole che tutti possano ripetere:

• Il QA testa solo un candidato bloccato.
• Promuovi lo stesso artefatto da QA a produzione.
• Ogni ambiente ha un proprietario e una cadenza di reset.
• Gli hotfix tornano sulla linea principale lo stesso giorno.

Checklist rapida per rilasci settimanali senza sorprese

Il rilascio settimanale funziona quando il team può rispondere con sicurezza a qualche domanda noiosa. Se rispondi "no" a due o più, aspettati fix dell'ultimo minuto e whiplash per il QA.

• C'è un branch che si può distribuire in sicurezza oggi? Dovrebbe buildare, passare smoke test ed evitare cambiamenti a metà.
• Le pull request restano piccole e atterrano entro uno o due giorni? Le PR a lunga vita di solito portano feedback obsoleti e conflitti maggiori.
• Il QA testa una build fissa, non un bersaglio in movimento? Il QA dovrebbe validare un numero di build o un candidato di rilascio specifico.
• Riesci a tenere il lavoro non finito fuori dal rilascio senza drammi? Feature flag, toggle di configurazione o una regola chiara di taglio dello scope.
• Qualcuno può eseguire un hotfix e rollback senza indovinare? Un runbook corto batte la conoscenza tribale.

Se vuoi un obiettivo misurabile: blocca il QA su un candidato di rilascio e mantienilo immutato tranne che per fix intenzionali.

Prossimi passi: scegli un cambiamento da provare la prossima settimana

Se il team è bloccato a discutere trunk-based vs GitFlow, non ridisegnare tutto in una volta. Scegli il problema che costa di più tempo e fai un piccolo esperimento per il prossimo rilascio.

Se i conflitti di merge sono il problema principale, accorcia subito la vita dei branch. Mira a far atterrare il lavoro quotidianamente (o a giorni alterni), usando feature flag quando necessario.

Se l'instabilità del QA è il problema maggiore, inizia bloccando ciò che il QA testa e definendo un semplice passo di promozione.

Un pilot leggero:

• Scegli un repo e un team.
• Imposta un limite di età per i branch (per esempio, nessun branch più vecchio di 2 giorni).
• Blocca il QA su una build e cambiala solo tramite promozione esplicita.
• Traccia tre numeri: tempo di risoluzione dei merge, ore di rework del QA e tempo hotfix→produzione.
• Riesamina dopo 2-4 settimane e aggiusta.

Se vuoi ridurre la pressione sui rilasci per strumenti interni o portali clienti, una piattaforma no-code come AppMaster (appmaster.io) può aiutare generando backend, web e app native pronte per la produzione da design visuale. Tuttavia beneficia ancora delle stesse abitudini sopra: piccoli cambi, candidati QA bloccati e un percorso di promozione chiaro.