Strategia per la creazione di branch: un percorso verso l'eccellenza

Quasi tutti i sistemi di controllo delle versioni oggi supportano i branch, le linee di lavoro indipendenti che derivano da un'unica base del codice centrale. A seconda del sistema di controllo delle versioni, il branch principale può essere definito mainline, predefinito o trunk. Gli sviluppatori possono creare i propri branch dalla riga di codice principale e lavorare in modo indipendente seguendo tale riga.

La creazione di branch consente ai team di sviluppatori di collaborare facilmente all'interno di una base del codice centrale. Quando uno sviluppatore crea un branch, il sistema di controllo delle versioni crea in quel momento una copia la base del codice. Le modifiche apportate al branch non influiscono sugli altri sviluppatori del team. Si tratta di un aspetto positivo, ovviamente, perché le funzioni in fase di sviluppo possono creare instabilità, con conseguenze che sarebbero dirompenti se tutto il lavoro avvenisse sulla riga di codice principale. Non è necessario, tuttavia, che i branch siano isolati. Gli sviluppatori possono utilizzare facilmente le modifiche di altri sviluppatori per collaborare alle funzioni e garantire che il loro branch privato non si discosti troppo da quello principale.

I modelli di creazione di branch spesso differiscono tra i team e sono oggetto di un intenso dibattito nella comunità software. Un tema importante è la quantità di lavoro che dovrebbe rimanere in un branch prima di essere nuovamente sottoposta a merge nel branch principale.

La creazione di branch di rilascio si riferisce all'idea che un rilascio sia interamente contenuto all'interno di un branch. Ciò significa che, alla fine del ciclo di sviluppo, il gestore dei rilasci creerà un branch dal branch principale (ad esempio, "branch di sviluppo 1.1"). Tutte le modifiche per la versione 1.1 devono essere applicate due volte: una volta al branch 1.1 e poi alla riga di codice principale. Lavorare con due branch costituisce lavoro aggiuntivo per il team ed è facile dimenticare di eseguire il merge di entrambi i branch. I branch di rilascio possono essere ingombranti e difficili da gestire poiché molte persone lavorano sullo stesso branch. Tutti conosciamo il dolore di dover eseguire il merge di numerose modifiche diverse su un unico branch. Se è necessario creare un branch di rilascio, crealo il più vicino possibile alla versione effettiva.

I branch di rilascio sono spesso associati ai flag delle funzioni, ovvero "interruttori" che abilitano o disabilitano una funzione all'interno del prodotto. Semplificano la distribuzione del codice nel branch principale e controllano lo stato di attivazione della funzione, facilitando la distribuzione iniziale del codice molto prima che la funzione sia visibile agli utenti finali.

In Atlassian utilizziamo un flusso di lavoro di branch per task. Ogni organizzazione ha un modo naturale di suddividere il lavoro in singoli task all'interno di uno strumento di monitoraggio dei ticket, come Jira. I ticket diventano, quindi, il punto di contatto centrale del team per quel lavoro. La creazione di branch dei task, nota anche come creazione di branch dei ticket, collega direttamente tali ticket con il codice sorgente. Ogni ticket viene implementato sul suo branch con l'identificatore ticket incluso nel nome del branch. Capire quale codice implementa i singoli ticket è semplice: basta cercare l'identificatore ticket nel nome del branch. Con questo livello di trasparenza, puoi applicare facilmente modifiche specifiche al branch principale o a qualsiasi branch di rilascio legacy a esecuzione prolungata.

Poiché Agile è incentrato sulle storie utente, i branch dei task si abbinano bene allo sviluppo Agile. Ogni storia utente (o correzione di bug) risiede all'interno del relativo branch; in questo modo, è facile vedere quali ticket sono in fase di avanzamento e quali sono pronti per il rilascio.

Tutti conosciamo il dolore di avere cercato di integrare più branch in un'unica soluzione ragionevole. In passato, il merge era un'operazione molto complessa a causa dei sistemi centralizzati di controllo delle versioni, come Subversion. I sistemi di controllo delle versioni più recenti, invece, come Git e Mercurial adottano un approccio diverso per tenere traccia delle versioni dei file che risiedono su branch diversi.

I branch sono in genere di breve durata, pertanto sono più facili da sottoporre a merge e più flessibili in tutta la base di codice. Tra la capacità di eseguire frequentemente e automaticamente il merge di branch come parte della continuous integration e il fatto che i branch di breve durata contengono semplicemente una minore quantità di modifiche, i "merge infernali" diventano un ricordo del passato per i team che utilizzano Git e Mercurial.

È questo che rende così fantastica la creazione di branch dei task!

Un sistema di controllo delle versioni può influire limitatamente sul risultato di un merge. Anche i test automatizzati e la continuous integration sono fondamentali. La maggior parte dei server di continuous integration può eseguire automaticamente test sui nuovi branch, riducendo notevolmente il numero di "sorprese" dell'upstream del merge finale e contribuendo a mantenere la stabilità della riga di codice principale.