In Artera abbiamo recentemente cambiato il software che utilizziamo per il controllo di versione, software conosciuti anche come Version Control Systems (VCS) o Source Code Management (SCM), durante lo sviluppo dei nostri siti web e applicazioni. In seguito ad un’analisi delle diverse soluzioni attualmente disponibili abbiamo deciso di passare a Git dismettendo SVN che abbiamo utilizzato fino ad ora.
VCS centralizzati
Il passaggio è stato quasi obbligato: SVN appartiene ancora alla “vecchia scuola” dei software per il controllo di versione centralizzati nati nella metà degli anni ottanta con CVS per permettere ad un gruppo di programmatori di lavorare ad uno stesso progetto contemporaneamente nel modo più semplice possibile.
I software centralizzati si basano su un architettura client/server: il server (repository) mantiene la storia del progetto, comprendente ogni cambiamento applicato al suo codice da quando questo è stato creato, mentre i diversi client possono connettersi al server per scaricare l’ultima versione ed inviare le modifiche implementate dagli sviluppatori.
Esiste quindi un singolo server (per questo centralizzato) che è l’unica entità a possedere lo storico del progetto e per poter utilizzare il software di controllo di versione è fondamentale avere un accesso a questo server.
I software di controllo di versione prevedono inoltre la creazione dei cosiddetti Branch ovvero la possibilità di ramificare lo sviluppo del progetto in linee “alternative” che possono essere utilizzate per due diversi scopi: l’implementazione di profonde modifiche del codice per questo interrompere lo sviluppo “principale” del software o la creazione di veri e propri progetti alternativi a partire da un unico “padre” e nessuno dei software rappresentanti di questa categoria offrono strumenti/funzionalità per gestire i branch in maniera adeguata, anche se questa non è una limitazione legata alla loro natura centralizzata, quanto a una mancanza di implementazione.
SVN, rispetto a CVS, migliora leggermente la situazione, rendendo più semplici alcune operazioni fondamentali ed è al momento lo standard de-facto che sta però lasciando il posto alla nuova generazione dei software distribuiti per il controllo di versione.
VCS distribuiti
Questa nuova tipologia di software non prevede più una rigida archittettura client/server ma gestisce in modo, appunto, distribuito lo sviluppo dell’applicazione. Ogni copia (clone) del progetto è, di fatto, un repository che contiene oltre alla versione di lavoro, anche tutta la storia del progetto. Ogni sviluppatore potrà lavorare sul progetto e “committare” le proprie modifiche offiline, senza essere collegati ad un server esterno. Successivamente potrà inviare tutte le proprie modifiche, in unica volta, su uno dei server dove il progetto è pubblicato. Anche la gestione di diverse linee di sviluppo può essere locale o remota, garantendo ancora più flessibilità durante lo sviluppo.
“Uno” dei server, proprio così, e non “Il” server poichè grazie a questa struttura, i sistemi distrubuiti permettono il deploy delle modifiche su diversi server incentivando così lo sviluppo comunitario di progetti o di, al contrario, lavorare senza avere affatto un server remoto.
I principali software di questo tipo nati di recente sono Git, Mercurial e Bazaar e hanno dato vita a vere e proprie social community di sviluppo come ad esempio Gitorius e Github, basati su git, che sono utilizzati per lo sviluppo di applicazioni e progetti come, rispettivamente: facebook, JQuery, MooTools, Apache e OpenSuse, KDE, WebKit. Mercurial ha dato vita a BitBucket su cui vengono sviluppati i software di Mozilla, Sun e Intel. Ed infine per bazaar abbiamo LaunchPad che ospita ad esempio MySQL.
La nostra scelta
I VCS centralizzati sono stati ovviamente scartati subito per le loro intrinseche limitazioni già descritte.
Tra i VCS distribuiti abbiamo scelto GIT per diversi motivi:
- Larga base d’uso che consente di avere molte fonti diverse per l’apprendimento del software
- Storicamente il più veloce
- Possibilità di utilizzare Gitorious come ottima interfaccia web, considerata la licenza OpenSource
- Disponilità di tool di facile uso per la conversione di repository SVN
- Disponibilità di una gran quantità di comandi utili per le più disparate esigenze
I vantaggi maggiori nel lavoro di tutti i giorni li abbiamo ottenuti grazie alla migliore qualità dei merge dei branch (ovvero il trasferimento di modifiche da un branch a un altro) e alla facilità d’uso di branch usa e getta. Vantaggi non legati in particolare a git in questo caso.
Per concludere, la conversione da SVN è stata pressoché indolore ed abbiamo solo toccato la punta dell’iceberg di ciò che è possibile fare ora che utilizziamo git ma il lavoro di squadra si è già semplificato di molto.
