Scrum e la branching strategy

In Scrum è fondamentale avere un prodotto rilasciabile alla fine di ogni Sprint. Per essere in grado di rilasciare così frequentemente è necessario avere una buona branching strategy. Fortunatamente ci sono gli strumenti che permettono di gestire il software nel miglior modo possibile sia in termini di tools che di processo.

Git e Gitflow

il sistema di versionamento più utilizzato per la gestione del codice sorgente è Git. Git dà la possibilità di creare branch in maniera molto semplice, veloce e senza richiedere troppe risorse hardware. In passato molte aziende utilizzavano SVN come sistema di versionamento preferito; uno dei più grossi vantaggi di Git rispetto ad SVN sta proprio nella facilità di creare branch sia locali che remoti.

GitFlow è un insieme di linee guida, che suggeriscono il miglior modo per gestire i branch con Git; seguendo le linee guida è possibile avere sempre delle versioni del software stabili che includono un insieme di funzionalità note.

Atlassian GitFlow

Sopra una figura che illustra la branching strategy consigliata da GitFlow. Nel branch master (azzurro) c’è l’ultima release ufficiale del prodotto; nel branch Develop (viola) c’è l’ultima versione completa delle funzionalità sviluppate; nei branch delle feature (verde) ci sono le funzionalità in via di sviluppo che ancora devono essere accorpate nel branch Develop. Questo tipo di gestione dei branch risolve molti problemi nella gestione del versionamento del codice. Inoltre aiuta ad avere nel branch Develop l’ultima versione stabile del prodotto comprensiva di tutte le feature implementate e che può essere rilasciabile in ogni momento.

Scrum e la branching strategy

Avere una branching strategy ben definita e che aiuta ad avere a disposizione un prodotto rilasciabile in ogni momento è la chiave per riuscire a rilasciare, se necessario, un incremento di prodotto dopo ogni Sprint. Anche se alcune funzionalità che devono essere implementate all’interno dello Sprint subiscono ritardi, non impattano il funzionamento del prodotto perchè rimangono sui feature branch senza essere accorpate al branch Develop. Una buona prassi è quella di eseguire i test di regressione automatici prima di accorpare il software su Develop; in modo da essere sicuri che tutte le funzionalità precedentemente implementate non siano impattate dai nuovi sviluppi.

Considerazioni finali

Nei progetti dove non è definita una branching strategy chiara e condivisa si creano problemi di conflitti di codice, perdita di modifiche al codice e regressioni dovute ai due problemi prima menzionati. Il prodotto è pronto per essere rilasciato, nella migliore ipotesi, quando è necessario fare una release ufficiale ogni 4-6 mesi.

Preoccuparsi della qualità e maturità del codice da rilasciare solo quando si arriva vicino alla data di rilascio ufficiale comporta problemi che potrebbero non essere risolvibili nel breve lasso di tempo che si identifica per stabilizzare il codice. Questo tipo di approccio porta a situazioni di forte stress dove diventa necessario lavorare al di fuori dell’orario di ufficio per cercare di recuperare problemi che il più delle volte non sono risolvibili velocemente. Aggiungere nuove funzionalità in incrementi di prodotto di breve durata temporale risolve questo tipo di problemi ed aiuta ad essere focalizzati sulle reali necessità degli utenti finali.

Se ti è piaciuto l’articolo Scrum e la branching strategy e t’interessa Scrum puoi leggere altri articoli nella sezione Agile