Si promuove l’artefatto, non il sorgente
Intro
Vedo ancora troppi team che “promuovono” il codice verso la produzione tramite i branch. Branch di develop, branch di staging, branch di release, branch di produzione… Un branch per ogni ambiente, ognuno con il suo significato speciale.
Questo approccio ha un nome: Gitflow. E per tanti anni è andato bene così. Ma secondo me è sbagliato.
Il problema: promuovere i sorgenti
Quando promuovi tramite branch stai dicendo: “questo codice è pronto, lo merge nel branch successivo”. E ogni volta che fai quel merge, stai ricreando qualcosa. Stai ricompilando qualcosa. Stai rigenerando qualcosa che in teoria avevi già validato.
E qui casca l’asino: quello che testi in un ambiente non è più la stessa cosa che arriva nell’ambiente successivo. Hai perso la garanzia.
Senza contare la complessità di gestire tutti quei branch, i merge, i conflitti, le cherry-pick, le regole su chi può fare cosa e dove.
L’alternativa: promuovere l’artefatto
L’approccio più corretto e anche più pratico è un altro. Trunk-based development con un unico branch di lunga vita. Da lì parte una pipeline di build che produce un artefatto. Quell’artefatto, immutabile, viene poi preso e fatto passare attraverso un funnel di deployment.
Questo funnel è una sequenza di ambienti: dev, test, staging, produzione. A ogni passaggio fai controlli di qualità: test automatici, approvazioni manuali, verifiche di sicurezza. Se va tutto bene, l’artefatto avanza. Se qualcosa non va, si ferma lì.
Nota che parlo di pipeline di build e pipeline di deployment come due cose separate. Non è detto che tu faccia continuous deployment o continuous delivery. L’importante è che il concetto sia chiaro: costruisci una volta, distribuisci molte volte. Build once, deploy many.
Il concetto chiave
Ogni volta che l’artefatto supera un ambiente con successo, lo stai promuovendo. Lo stai certificando. Lo stai avvicinando alla produzione. E questo a prescindere dal branch da cui è stato generato.
Il branch ti dice da dove viene il codice. L’artefatto ti dice cosa stai rilasciando. Sono due cose diverse.
“Ma la tracciabilità?” Certo che serve. Da quell’artefatto devi sapere quale commit l’ha generato. Ma tutte le piattaforme moderne, da Azure DevOps a GitHub Actions fino a GitLab, rendono questa cosa banale. Non hai bisogno di branch dedicati per sapere cosa c’è dentro un rilascio.
Azioni
La prossima volta che guardi la tua branching strategy, chiediti:
- Sto promuovendo branch o artefatti?
- L’artefatto che arriva in produzione è lo stesso identico che ho testato negli ambienti precedenti?
- Ho davvero bisogno di tutti questi branch di lunga vita?
Se la risposta alla prima domanda è “branch”, hai del lavoro da fare. Parti dal concetto: si promuove l’artefatto, non il sorgente.
Sharing is caring
Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!