3.3.1
Adozione di un server GitLab aziendale
Tradizionalmente in azienda i sorgenti sono stati versionati con la tecnologia SVN o con GIT.
SVN `e una soluzione esclusivamente client-server, quindi non pu`o essere impiegata senza disporre di una opportuna infrastruttura di rete. Inoltre `e una soluzione pi`u datata che sta lentamente venendo soppiantata per via dell’esistenza di alternative che hanno un corredo di features migliore ed un parco di software pi`u completo. Anche noi abbiamo seguito questo trend e da diversi anni a questa parte usiamo esclusivamente GIT.
GIT permette di operare in maniera serverless, versionando i sorgenti su un repository locale che pu`o funzionare perfettamente anche in assenza di rete. Questa copia locale pu`o essere allineata periodicamente con una remota (detta origin) allo lo scopo di mantenere un backup ed avere un luogo centralizzato con cui condividere il lavoro con il team.
L’azienda non disponeva di un server GIT interno e non ha mai voluto ospitare i sorgenti presso provider esterni (quali ad esempio GitHub, BitBucket) quindi questi venivano conservati in una NAS (Network Area Storage).
Bench´e questa soluzione sia perfettamente funzionante dal punto di vista tecnico non `
e ottimale.
Quando si accede al repository tramite una network share il sistema operativo mette in atto un’astrazione per mascherare l’effettiva collocazione sulla rete rendendola acces- sibile con un normale path di sistema. In un contesto del genere, il software Git pensa di disporre dei sorgenti in locale ed opera un accesso al file system aggressivo. Questa mole di I/O quando viene veicolata sulla rete ne mette in evidenza i limiti. In particolare la latenza diventa una metrica non pi`u trascurabile ed in particolari condizioni pu`o risultare addirittura inaccettabile.
Per questo progetto capit`o spesso di dover lavorare fuori dall’ufficio tramite una VPN su rete geografica pubblica. Durante le operazioni sul repository pi`u onerose (es. merge) capitava che queste andassero in timeout per via dell’inadeguatezza del canale di comunicazione rapportato alla policy di accesso ai files usata dal client git.
´
E stata questa la motivazione principale che ci ha spinto a dotare l’infrastruttura di rete aziendale di un server GIT.
Tra le varie soluzioni installabili in maniera standalone abbiamo scelto GitLab1perch´e
dimostrava di avere una certa robustezza, era free (e lo `e ancora in parte al momento della presentazione di questa tesi) ed `e ben supportato. Questo oltre ad offire la funzionalit`a core che cercavamo (cio`e la gestione di un server GIT remoto) offre altri strumenti interessanti utili nell’intero ciclo di sviluppo software.
Le principali funzioni offerte da GitLab sono:
Un’interfaccia web ben fatta per l’amministrazione dei repository e degli utenti. Un sistema basilare di gestione di issues. Nonostante questo non abbia tutte le fea-
tures di un sistema di ticketing support `e comunque un valido strumento perch´e per- mette di fare delle annotazioni che referenziano i sorgenti e di derivare direttamente un branch dove ospitare gli sviluppi associati alla issue.
Ha una gestione interna di Wiki, che permette di creare un mini sito di progetto dove inserire le informazioni di partenza necessarie per gli sviluppatori per comin- ciare a contribuire. Questo viene generato automaticamente dal sistema parsando i files scritti in linguaggio Markdown2 versionati insieme ai files del progetto.
Offre funzioni di Continuous Integration/Continuous Deployment.
Queste inizialmente non sono state una metrica che ci ha fatto preferire GitLab ad altre soluzioni ma col senno del poi possiamo dire che `e risultato estremamente vantaggioso avere un’unica soluzione centralizzata. Se avessimo scelto un gestore di repository diverso tra quelli disponibili sul mercato (es. BitBucket, GitBucket, Gogs) nessuno di queste avrebbe offerto funzionalit`a di DevOps e sarebbe risultato necessario dover attivare un altro server con un software specifico (quale ad esempio Jenkins). Questo avrebbe richiesto una laboriosa fase di configurazione per farli dialogare.
3.3.2
Adozione della strategia ’Feature Branch’
L’idea era quella di limitare il pi`u possibile la comparsa di conflitti di versione da gestire. Nel caso in cui questi erano inevitabili (ad esempio perch´e gli stessi file erano stati modificati su 2 filoni di progetto distinti) il problema doveva comunque sollevarsi prima del momento del merge finalizzato al rilascio, cio`e durante la fase di sviluppo.
Per raggiungere questo obiettivo abbiamo adottato una strategia nota in letteratura con il nome di ’Feature Branching’ [5] impiegandola con approcci a corto ciclo di sviluppo tipici della metodica eXtreme Programming.
Le regole da rispettare sono le seguenti:
Bisogna designare un branch per essere quello mainline, ossia quel branch in cui ogni commit corrisponde ad una versione stabile del sistema. Noi abbiamo scelto quello master. L’idea `e che questo branch debba sempre contenere una release stabile, in modo che vi si possano stratificare sopra veloci bugfix e poter rilasciare immediatamente, senza avere di intralcio le commit relative a features incomplete (che ne impedirebbero la rilasciabilit`a).
Ogni feature che prospetta una certa laboriosit`a deve essere necessariamente ver- sionata su un branch diverso da quello master.
Ogni membro attivo sullo sviluppo di una feature deve controllare spesso il master branch, pullando nella sua copia locale le modifiche avvenute sull’origin e mergen- dole sulla sua copia locale del suo branch feature. Questa operazione `e nota come rebase ed ha lo scopo di anticipare la scoperta di eventuali conflitti di versione. Ap- plicando questa regola con diligenza si ha il benefico effetto per il quale il branch della feature contiene sempre al suo interno la storia del master (cio`e del branch con cui dovr`a fare il merge una volta completata). Un merge tra 2 branch che condividono una storia comune `e noto come fast-forward e non produce mai effetti collaterali. L’altro vantaggio `e che il branch della feature, con al suo interno le ver- sioni aggiornate del master `e in sostanza il futuro master branch, quindi ogni test condotto su di esso `e particolarmente significativo perch´e anticipa il funzionamento che avr`a il sistema una volta in produzione.
Ogni modifica potenzialmente impattante per il resto del team deve essere pushata il prima possibile in modo che il resto del team possa prendere atto di questo aggiornamento e provvedere a gestire eventuali conflitti il prima possibile. Questo approccio ha lo scopo di ridurre la comparsa o l’entit`a dei merge-hells. Arrivando alla realizzazione della feature principale attraverso micro sviluppi incrementali e condivisi.
Questo workflow funziona bene se tutti i membri rispettano le regole. Nel nostro caso non sono mai capitati problemi in quanto il lavoro era stato preliminarmente suddiviso in modo da ridurre le aree di intersezione. Per quelle volte in cui occorreva fasarci risolvevamo con un coordinamento manuale, reso possibile dal fatto che il team era particolarmente piccolo.
Per progetti in cui sono coinvolti pi`u sviluppatori (magari distribuiti geograficamente o su diversi fusi) definire delle regole potrebbe non bastare per ottenere un coordinamento sufficiente. In quest’ottica GitLab mette a disposizione 2 strumenti.
Una `e quella delle pull request3. Serve per invitare gli altri membri del team a preleva- re delle modifiche che sono state pushate, senza aspettare che siano loro proattivamente a controllare il changelog e a realizzare di avere a bordo sul loro repository locale una versione obsoleta.
L’altro strumento `e quello dei protected branches. L’operazione di push su certi branch pu`o essere limitata in modo che questa sia consentita solo previo superamento di una serie di requisiti di sbarramento. Questi possono essere ad esempio l’ottenimento di un’approvazione da parte del responsabile di progetto o da parte di un numero minimo di altri membri del team.