Git flow: A supporto del continuous software development
In ambito sviluppo è molto importante il concetto di VCS Version Control System, in quanto consente a più sviluppatori o a team di lavorare in modo isolato su uno stesso progetto senza influire sul lavoro degli altri. Questo isolamento consente di costruire, testare, integrare o addirittura eliminare le funzionalità in modo controllabile, trasparente e mantenibile.
Il VCS è un sistema che consente di gestire la modifica dei software in fase di sviluppo; più nel dettaglio registra le modifiche che un file, o un insieme di questi, subiscono nel tempo, in modo da poter accedere a tutti i dettagli relativi alle modifiche individuando non solo quando ma anche chi ha apportato una determinata modifica.
Questo consente non solo di tenere monitorata l’intera fase di sviluppo e di poter confrontare le modifiche che un file ha subito nel tempo, ma anche di ripristinare file selezionati, o addirittura l’intero progetto, a uno stato precedente (revert). L’uso di un VCS aiuta anche in fase di gestione di bug con la possibilità di fare revert dello sviluppo fino ad un punto precedente nel quale il bug non era ancora stato introdotto.
Le principali tipologie di VCS
Centralized Version Control Systems (CVCSs)
Questi sistemi hanno un singolo server che contiene tutti i file versionati, dal quale diversi client prelevano i file. Il maggior difetto di questa architettura è proprio il server centralizzato, in quanto tutto il progetto e la sua history risiedono in un unico punto con il rischio di perdere tutto in caso di danneggiamento o in assenza di backup o ancora in caso non si possano salvare modifiche se è down.
Distributed Version Control Systems (DVCSs)
In questa architettura i client si creano una copia dell’intera repository, inclusa la sua history; di conseguenza ogni clone è un vero e proprio backup di tutti i dati. Di questa ultima categoria fa parte GIT.
Git è un sistema di versionamento open source che si differenzia dagli altri grazie al suo branching model (flussi di lavoro multipli) che incoraggia molteplici branch locali indipendenti l’uno dall’altro.
Il branching model favorisce lo sviluppo di applicativi da parte di team consentendo a più persone di lavorare allo stesso progetto (e agli stessi files) contemporaneamente.
GIT si basa su due principali branch:
– MASTER/MAIN: branch dedicato alla produzione
– DEVELOP: branch di sviluppo dove vengono eseguiti i test e uniti i singoli branch di sviluppo di una feature, ovvero di una funzionalità che deve essere sviluppata. Infatti, alla base di GIT troviamo un workflow basato sulle funzionalità, promuovendo la creazione un nuovo branch per ogni nuova funzione su cui sta lavorando.
Questo consente un facile switch tra branch in modo da poter passare senza problemi da uno all’altro.
Terminato lo sviluppo di una funzionalità, il branch di sviluppo viene eliminato unendolo (mergiandolo in termini tecnici) a quello ufficiale di sviluppo e test (DEVELOP).
Una volta terminati i test, quando si vuole passare in produzione si unisce il tutto in MASTER/MAIN.
Da questo concetto si sono sviluppati diversi Workflow tra i quali io prediligo Gitflow.
Gitflow
Inizialmente pubblicato da Vincent Driessen at nvie, è un workflow Git cha aiuta nel continuous software development e definisce un branching model ben definito orientato a progetti schedulati da ciclici rilasci tramite release. La sua particolarità è di non aggiungere nessun nuovo concetto alla struttura base di GIT, rimanendo negli standard definiti, fattore molto importante nello sviluppo, ma assegna ruoli specifici a differenti tipi di branch in base al loro scopo, definendo inoltre quando questi dovranno interagire tra loro e aiutando così gli sviluppatori a seguire un determinato flusso di lavoro.
I comandi introdotti, infatti, non sono altro che un raggruppamento di alcuni comandi base di GIT.
Esempio:
gitflowgitgit flow release finish 1.2.0git checkout mastergit merge –no-ff release/1.2.0git tag -a 1.2.0git checkout developgit merge –no-ff release/1.2.0git branch -d release/1.2.0
Branch e il loro scopo
Feature
Branch base già visto in GIT che ha origine da DEVELOP e una volta terminato viene mergiato nello stesso. Viene utilizzato in fase di sviluppo, generalmente se ne trova uno per ogni funzionalità richiesta. Consente lo sviluppo parallelo.
Release
Ha origine da DEVELOP e contiene un insieme di funzionalità in fase di preparazione per essere testate e pubblicate. Infatti, non può contenere nuovi feature branch ma solamente bug fixes, documentazione, consentendo di “fissare” lo sviluppo fatto fino a quel momento. Questo consente ad un altro team di proseguire con lo sviluppo di nuove funzionalità partendo da DEVELOP con i FEATURE.
Una volta terminato e testato, pronto quindi per essere messo in produzione, questo branch viene mergiato in MASTER/MAIN e in DEVELOP ed inoltre viene taggato con una nuova versione. Successivamente il branch viene rimosso.
Hotfix
Ha origine da MASTER/MAIN in quanto deve essere una veloce correzione di un eventuale bug presente in produzione.
Completato, deve essere mergiato in MASTER/MAIN e DEVELOP (o eventuale Release), taggando MASTER/MAIN con un aggiornamento di versione.
GOLDEN RULES
A develop branch is created from master/main
A release branch is created from develop
Feature branches are created from develop
When a feature is complete it is merged into the develop branch
When the release branch is done it is merged into develop and master
If an issue in master/main is detected a hotfix branch is created from master
Once the hotfix is complete it is merged to both develop and master/main
