Continuous delivery super potente con Git

A dire il vero, non è che Git di per sé sia così perfetto per la continuous delivery. È che i flussi di lavoro della creazione di branch sono ottimi per la CD e Git è ottimo per i flussi di lavoro della creazione di branch. Oltre ad essere l'amico del cuore della CD, un flusso di lavoro branch-e-merge consente di affrontare bug complicati, provare nuove tecnologie o semplicemente iniziare a codificare una nuova funzione da zero senza il rischio che le modifiche impediscano agli altri membri del team di andare avanti con i propri task.

Chiaramente, anche Subversion e altri sistemi di controllo delle versioni tradizionali consentono di creare i branch. Ma mettiamoli da parte per un momento e conosciamo il gemello cattivo della creazione di branch: il merge.

I sistemi di controllo delle versioni tradizionali come Subversion semplicemente non riescono a tenere bene traccia delle versioni dei file che risiedono in branch diversi e, quando arriva il momento di eseguire il merge, Subversion deve fermarsi e chiedere spesso indicazioni (hai presente... quel piccolo pop-up che chiede quale riga inserire nella versione sottoposta a merge). Il fatto che durante i merge sia necessario un tale livello di interazione umana spinge i team a istituire blocchi del codice per fare in modo che chi stia eseguendo il merge non venga interrotto dalle nuove modifiche in arrivo in uno dei branch. E i blocchi del codice sono costosi: si tratta di intervalli di tempo piuttosto improduttivi.

Git, invece, riesce benissimo a tenere traccia delle modifiche apportate a diverse versioni di file che risiedono su branch diversi e conosce sempre l'aspetto del predecessore comune del file in questione. Quindi, fondamentalmente è come se avesse un GPS integrato tramite cui può spostarsi nei merge senza doversi fermare e chiedere sempre indicazioni.

Con Git, hai la libertà di sfruttare il potere della creazione di branch in un modo che sarebbe poco pratico con Subversion. Le spese generali legate alla creazione di branch e al merge sono così insignificanti che i branch che vivono solo per un giorno o due diventano non solo fattibili, ma anche utili.

Ok, perfetto. Ma esattamente cosa rende la creazione di branch così potente per la continuous delivery?

Ad esempio, tutti i team di sviluppo di Atlassian hanno un accordo secondo cui nulla viene mai sottoposto a commit direttamente nei branch principali o stabili. Tutti svolgono il proprio lavoro sui branch. In effetti, siamo così ottimisti riguardo alla creazione di branch che abbiamo deciso di creare un branch separato per ogni ticket Jira che gestiamo (ne parleremo tra poco).

In ogni caso, questo significa che ognuno può fallire tutti i test e fare tutti i danni che vuole sui propri branch! Il branch principale rimane in uno stato da cui è possibile effettuare il rilascio e creare nuovi branch senza ereditare il codice errato. E questo è un grande vantaggio per la CD e per la produttività generale degli sviluppatori (per non parlare del loro morale).

Con i branch è più semplice accettare i contributi esterni al team

L'utilità di Git per la creazione di branch, e in particolare per il fork di interi repository, semplifica la raccolta dei contributi di persone esterne al team: collaboratori esterni, sviluppatori di società partner, sviluppatori di altre unità aziendali e così via. Non devi passare notti insonni a preoccuparti che chi non conosce la base di codice apporti in modo disorganizzato modifiche ai branch più importanti e ostacoli il rilascio di nuovo codice.

Anche in questo caso, rigorosi test automatizzati sui branch o sui repository con fork sono la chiave per la collaborazione perfetta. Ti consigliamo di esaminare i risultati di compilazione e test prima di approvare qualsiasi merge nella riga di codice principale.

Creazione di branch corretta = chiarezza nel monitoraggio del progetto

Di tendenza: crea un branch di sviluppo per ogni story, correzione di bug o task (ad esempio, ogni ticket Jira) che implementi. Abbiamo adottato questo modello di branch-per-ticket in Atlassian anni fa e non siamo mai tornati indietro! È diventato popolare anche tra i nostri clienti.

La creazione di un branch per ogni ticket semplifica la selezione manuale delle modifiche da rilasciare nell'ambiente di produzione o da raggruppare in un rilascio. Dal momento che non si accumulano modifiche sul branch principale, puoi scegliere cosa inserire in quest'ultimo e quando. Puoi rilasciare un MVP di un epic più uno preferenziale, piuttosto che aspettare che tutti quelli preferenziali siano pronti. Oppure puoi rilasciare una singola correzione di bug e farlo nell'ambito del framework o di un normale rilascio. Anche se la correzione è urgente, non dovrai fare i conti con il processo confusionario di ritirare le altre modifiche che non sono ancora pronte per il rilascio solo per rilasciare quell'unica modifica.

E la facilità di rilascio delle singole modifiche del codice è l'essenza della continuous delivery.

Questo approccio non solo tiene lontano il codice non verificato dal branch principale, ma includendo l'identificatore ticket Jira e il nome o le iniziali dello sviluppatore pertinenti nel nome del branch, lo stato di sviluppo per ogni ticket in corso risulterà chiarissimo.

Osserva la convenzione di denominazione usata nell'immagine sopra: è l'identificatore univoco del ticket Jira in fase di implementazione, più una breve descrizione leggibile dell'argomento del ticket. Quindi, in qualità di release manager o altro stakeholder, puoi dare un'occhiata al repository mostrato sopra e sapere a colpo d'occhio che la storia utente tracciata da AMKT-13952 è pronta per il rilascio perché puoi vedere che è stata sottoposta a merge nel branch principale. E così è possibile ottenere tracciabilità senza nessun intervento manuale: boom!

Ottima domanda! In questo articolo lo descriverò rapidamente e nei suoi aspetti generali, visto che le sue singole fasi sono descritte nei dettagli in altri articoli di questo sito.

• Crea un branch per il ticket su cui stai per lavorare. Includi l'identificatore ticket Jira nel nome del branch in modo che ne sia chiaro lo scopo. Se utilizzi strumenti Atlassian come Bitbucket e Bitbucket Pipelines, questi ultimi si ricollegheranno all'identificatore ticket e creeranno link tra il ticket, il branch, tutti i commit, le build, le pull request e le distribuzioni relativi a quel ticket. In altre parole, gli identificatori ticket sono magici.
• Apporta le modifiche al branch. Qui sei nel tuo mondo, quindi scatenati. Prova cose nuove. Rompi quello che vuoi. Non importa, perché poi...
• Inserisci il branch nel processo di CI. Spetta a te e al tuo team decidere se eseguire in questa fase test specializzati come i test di carico o i test end-to-end basati sull'interfaccia utente e se attivare automaticamente un test ogni volta che invii modifiche al branch. I team di Atlassian generalmente eseguono test a livello di unità e integrazione sui branch di sviluppo.
• Aggiorna frequentemente il branch con le ultime modifiche del branch principale. Puoi usare i comandi rebase o branch-commit per farlo. Dipende totalmente da te (ma ricorda di non riassegnare un branch che condividi con altri sviluppatori, perché questo li farà arrabbiare). In ogni caso, rileverai i conflitti di integrazione prima di eseguire il merge, il che a sua volta aiuta a mantenere pulito il branch principale.
• Crea una pull request quando è tutto pronto per il merge verso l'alto. Ciò significa che l'implementazione è completata, che hai inserito le modifiche degli altri membri del team, risolvendo i conflitti che ne sono derivati, e che tutti i test eseguiti sul branch sono stati superati.
• Esegui il merge e distribuisci a tuo piacimento. Alcuni team preferiscono rilasciare automaticamente ogni modifica non appena viene sottoposta a merge nel branch principale e tutti i test vengono superati, seguendo quindi il modello di continuous deployment. Altri team preferiscono prendere una decisione autonoma su quali modifiche rilasciare e quando. Dipende da te e dal tuo team.

Quindi il gioco è fatto. I flussi di lavoro della creazione di branch semplificano la proposta di continuous delivery con il contributo di Git che ne elimina i grattacapi. Continua a leggere per approfondire la configurazione del repository Git in modo che sia compatibile con la CD e per scoprire come mettere in pratica tutte queste idee utilizzando gli strumenti Atlassian. Ci vediamo alla pagina successiva!