Close

Continuous delivery super potente con Git

Ora che Git ha risolto il problema del merge, i flussi di lavoro della creazione di branch sono molto più interessanti.

Primo piano di Sarah Goff Du-Pont
Sarah Goff-Dupont

Principal Writer


Sappiamo tutti che è meglio fare attenzione al codice scritto da una sola persona e conosciamo i vantaggi della creazione di software in team: si hanno modi di pensare diversi, background ed esperienze variegati... e quando queste differenze si applicano a qualsiasi problema si stia cercando di risolvere, si finisce con il creare un software migliore, più gestibile, di qualità superiore e, in definitiva, in grado di servire meglio l'utente.

Collaborazione in team | CI/CD Atlassian

Ma ecco un'altra cosa che sappiamo: crescere come team può essere complicato!

Si cerca di capire a quali parti di codice stanno lavorando tutti, di assicurarsi che le modifiche non siano in conflitto, di trovare i difetti prima che lo facciano i clienti e di tenere tutti connessi al progetto e aggiornati sull'avanzamento del lavoro. A quanto pare, ognuno di questi problemi viene risolto mediante la creazione di branch Git o la continuous delivery.

Spero di convincerti che, combinando le due cose (e magari inserendo alcuni fantastici strumenti nel mix solo per divertimento), avrai una ricetta super potente per il successo.

La potenza dei flussi di lavoro basati sui branch


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.

Diagramma del flusso di lavoro di base | CI/CD Atlassian

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?

I branch mantengono il branch principale pulito e rilasciabile

Abbiamo stabilito che i branch di breve durata offrono agli sviluppatori un ottimo modo per collaborare a un progetto o a una funzione senza disturbarsi a vicenda. Ma soprattutto per la CD, l'isolamento di tutto il lavoro in corso sui branch di sviluppo mantiene i branch principali e quelli di versione stabile in uno stato pulito in modo da poter eseguire il rilascio quando si preferisce.

Ciò significa eseguire la serie completa di test automatizzati sui branch di sviluppo in modo che gli sviluppatori possano verificare chiaramente la qualità del codice e decidere con sicurezza quando le modifiche saranno pronte per essere sottoposte a merge (se ancora non padroneggi i test automatizzati, dai un'occhiata a questo post di RebelLabs per leggere una conversazione divertente e le procedure da seguire per scrivere i primi test unitari).

Significa anche utilizzare le pull request di Git come forma di revisione del codice in modo che l'intero team abbia fiducia nella gestibilità e nell'interoperabilità del codice con altre aree della base di codice. Sì, ciò comporta un maggiore lavoro iniziale rispetto a quanto richiesto dai modelli di distribuzione tradizionali. E sì, ne vale la pena.

Scopri la soluzione

Compilare e gestire software con Open DevOps

Materiale correlato

Cos'è la pipeline DevOps?

Una continuous delivery di successo implica il mantenimento dei branch di rilascio puliti

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.

Screenshot del repository Git dei commit di Bitbucket | CI/CD Atlassian

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!

Allora come funziona il flusso di lavoro Git + continuous delivery?


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.
Automazione CI Git | CI/CD Atlassian

In conclusione...


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!

Sarah Goff-Dupont
Sarah Goff-Dupont

Sarah è un QA Engineer diventata scrittrice il cui lavoro è stato pubblicato su Harvard Business Review, Inc., Huffington Post e in pubblicazioni di settore. Lavora a distanza da casa sua in Minnesota e le piace ogni minuto. Quando non scrive, puoi trovarla a leggere, fare snowboard, cucinare e/o scambiare giochi di parole ridicoli con i suoi figli.

Contatta Sarah su LinkedIn


Condividi l'articolo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Leggi il blog

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up