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

O creazione di branch di task a modo tuo, o creazione di branch di rilascio: sei tu che scegli.

Dan Radigan Di Dan Radigan
Esplora argomenti

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.

Perché preoccuparsi della creazione di branch?

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.

Suggerimento

I branch non sono efficaci solo per il lavoro sulle funzioni. Possono isolare il team da modifiche importanti dell'architettura, come l'aggiornamento di framework, librerie comuni e così via.

Tre strategie di creazione di branch per i team Agile

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.

Creazione di branch di rilascio

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.

ATTENZIONE:

La creazione di branch di rilascio è un aspetto importante del supporto delle varie versioni software disponibili sul mercato. Un singolo prodotto può avere diversi branch di rilascio (ad esempio, 1.1, 1.2, 2.0) per supportare lo sviluppo. Tieni presente che le modifiche alle versioni precedenti (ad esempio 1.1) potrebbero dover essere unite ai branch di rilascio successivi (ad esempio 1.2, 2.0). Dai un'occhiata al nostro webinar qui sotto per maggiori informazioni sulla gestione dei branch di rilascio con Git.

Creazione di branch di funzioni

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.

Suggerimento:

Un altro vantaggio del flag delle funzioni risiede nel fatto che il codice può rimanere all'interno della build ma è inattivo durante la fase di sviluppo. Se qualcosa va storto quando la funzione è abilitata, un amministratore di sistema può annullare il flag delle funzioni e ripristinare uno stato valido noto invece di dover distribuire una nuova build.

Creazione di branch di task

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.

Ora ti presentiamo il gemello cattivo della creazione di branch: il merge

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!

Convalida, convalida e convalida di nuovo

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.