Cos’è un sistema di versionamento?

La definizione più generica di sistema di versionamento o VCS (Version Control System) è: strumento che aiuta a gestire i cambiamenti nel codice sorgente nel tempo.

Un sistema di versionamento permette ad ogni singolo membro del team in maniera più efficiente, veloce e intelligente. L’adozione di uno strumento simile riduce i tempi di sviluppo e aumenta i rilasci andati a buon fine.

Il tutto è possibile grazie ad una serie di funzionalità che fanno dei sistemi di versioning un asset fondamentale per lo sviluppatore moderno.

Prima però di approfondire le funzionalità di un VCS è giusto specificare cosa NON è un sistema di versionamento.

Segni che non stai usando un sistema di versionamento

• Non sai quali modifiche sono state fatte nel tempo ad uno specifico file
• I conflitti che si generano dopo ingenti modifiche non riesci a risolverli in tempi rapidi
• I tuoi file hanno come desinenza “final”, “latest” o simili
• Hai pezzi di codice commentati qui e là perché ti sei detto “Non si sa mai”

Se ad alcuni o tutti questi punti hai annuiti significa che non stai usando in maniera efficiente un sistema di versionamento.

Nel workflow di uno sviluppatore, nel mio caso specifico sviluppatore web, un tool per versionare il proprio codice è fondamentale per non incappare nelle problematiche sopra elencate, ma soprattutto per i diversi vantaggi che un VCS porta con le sue funzionalità.

Le funzionalità principali di un VCS

Come menzionato in precedenza un Version Control System ha diverse funzionalità, nello specifico:

• Cronologia completa delle modifiche di un file (creazione, cancellazione, modifica, spostamento e cancellazione). Ognuna di queste è accompagnata da ulteriori informazioni come autore, data e note sulla modifica.
• Possibilità di divergere e lavorare in flussi di modifiche isolati, chiamati rami, evitando la concorrenza. Questa funzionalità è nota come branching o ramificazione.
• I flussi isolati possono essere riunificati in qualsiasi momento al flusso principale. Questo si chiama merging o unificazione.
• Verifica e segnalazione preventiva dei conflitti così da evitare di portare dei malfunzionamenti inattesi nel flusso principale.
• Nel caso di errore si può “tornare indietro” ad una versione precedente, correggendo l’errore ed evitando malfunzionamenti prolungati.

Con delle funzionalità del genere un VCS, oggi, è un must have e non un surplus. Questo si applica perfettamente anche ai progetti più piccoli.

Sia chiaro… è possibile sviluppare senza un VCS, ma farlo sottopone il progetto a rischi enormi di cui nessuno dovrebbe prendersi carico.

Per arrivare a tutto questo però ne è stata fatta di strade dalle primissime VCS locali. Vediamo quindi di ripercorrere la storia dei sistemi di versionamento.

L’evoluzione dei sistemi di versionamento

Esistono tre tipologie di VCS: locali, centralizzati e distribuiti. Oggi usiamo le distribuiti, ma la loro struttura non è altro che la fusione degli altri due sistemi. Vediamoli uno per uno.

Sistemi di versionamento locali

I VCS locali sono composti da un database di versionamento speciale, il cui compito è quello di memorizzare i cambiamenti dei file. L’ultima versione nel database corrisponde alla versione più recente del file nella cartella di lavoro (chiamato checkout).

Il problema di questo sistema era la mancata possibilità di poter collaborare con altri programmatori su altri sistemi. Per farlo i LVCS (Local Version Control System) sono diventati centralizzati.

Sistemi di versionamento centralizzato

Il database di versionamento viene spostato su un server appositamente configurato il quale contiene il database di versionamento. I vari client (computer dei vari programmatori) si connettono a questo database e sincronizzano le proprie versioni caricando nuove versioni o scaricando le nuove modifiche.

La collaborazione e il versionamento era possibile, ma c’è un problema. Il server.

Eh già… Il server in questo bello schema è il punto di rottura dell’intero sistema. Se per qualche motivo il server doveva essere messo offline per manutenzione il team non poteva lavorare e se nel caso d’incendio il server andava in fumo insieme ai backup, settimane se non mesi di lavoro andavano perduti.

Era necessario quindi una nuova evoluzione, quella che ci ha portato dai CVCS (Centralized Version Control System) ai DVCS (Distributed Version Control System).

Sistemi di versionamento distribuito

Oggi usiamo questo sistema, un ibrido di entrambi i sistemi visti in precedenza. Il sistema di versionamento distribuito o DVCS prevede sempre un server con il database di versionamento, ma i client hanno una replica del database e la versione finale dei vari file.

Se Computer A perde tutti i file può sempre ripristinare il lavoro scaricando l’ultima versione salvata dal server o da Computer B (dipende dalla configurazione). Stesso discorso vale per Computer B e per il Server. Solo una gigantesca serie di incredibilmente sfortunati eventi può portare alla perdita di dati da tutti e tre gli attori coinvolti.

Il DVCS più noto è Git, il quale è gratis e open source, ma di questo ne parlo in maniera decisamente più approfondita qui.

Conclusioni

Arrivati a questo punto dovrebbe essere chiaro il ruolo di una VCS, ma c’è da tenere a mente un altro paio di cose. La prima è che un buon VCS supporta il workflow dello sviluppatore senza imporre paradigmi di alcun tipi. Tradotto: massima libertà. Nota: va bene la libertà, ma ricorda cosa disse zio Ben: <>.

Ultima cosa, ma non per questo meno importante, ricorda che la domanda che ti dovrai porre non è se usare una VCS, ma quale.