DVCS... Chi era costui?

In questo articolo ci concentreremo sullo spiegare le situazioni in cui i sistemi distribuiti offrono i maggiori vantaggi rispetto alle soluzioni centralizzate ben più diffuse e note e che quindi non necessitano degli stessi chiarimenti. Cercheremo anche di separare le caratteristiche di livello implementativo, come particolari comandi o un’eventuale interfaccia grafica, da quelle dovute al cambio di workflow del nuovo sistema.

La storia dei sistemi centralizzati OpenSource inizia molti anni fa con RCS e passando per CVS arriva all’ultima incarnazione chiamata Subversion che può essere considerato il software di VCS più diffuso e utilizzato al mondo.

I sistemi centralizzati si caratterizzano per il fatto che esiste un solo repository centrale a cui tutti gli sviluppatori devono fare riferimento per lo sviluppo. Proprio in questo consiste la principale differenza con i sistemi distribuiti dove, sebbene possa esistere un unico repository a cui tutti fanno riferimento, ciascuno sviluppatore nel momento del checkout crea localmente una copia identica del repository principale e può quindi lavorare localmente senza bisogno di continua sincronizzazione oppure può scegliere di sincronizzarsi con repository diversi da quello principale.

Questa differenza ne introduce contemporaneamente un’altra riguardante l’atto pratico dell’utilizzo: poiché la copia locale del repository è identica a quella remota, il singolo passo di commit dei sistemi centralizzati viene diviso in commit e push, ovvero nella conferma dei cambiamenti registrando il changeset in locale e la copia dei nuovi changeset nel repository remoto di riferimento (o di nostra scelta, non siamo più vincolati al nostro repository principale).

Per procedere nell’analisi però diventa utile introdurre alcuni workflow che si differenziano per essere i più frequentemente presenti nelle nostre lunghe giornate di lavoro. Analizzeremo quindi il comportamento dei due concorrenti alla prova dei fatti.

Sviluppo Centralizzato

Figura 1. La figura rappresenta lo schema logico di funzionamento di un sistema centralizzato

Il primo, e più scontato, flusso è quello tipico dei sistemi centralizzati, si può dividere nei passi:

1. Checkout del repository principale
2. Modifica locale
3. Commit dei cambiamenti
4. Push dei changeset sull'albero principale (solo nei sistemi distribuiti)

Non esistono particolari problemi strutturali che possano impedire ai sistemi distribuiti di funzionare in questo modo e ovviamente i sistemi centralizzati sono stati creati per supportare principalmente questo ciclo di sviluppo.

Sviluppo Branch-Based

Figura 2. In figura è rappresentato lo schema logico dello sviluppo branch based. Le frecce indicano la direzione dello scambio di dati ed è possibile notare che nei sistemi distribuiti questo può avvenire anche tra i computer degli sviluppatori e non solo tra l'albero principale e i branch.

Negli ultimi anni si sta affermando un sistema di sviluppo che si fonda sul funzionamento continuo del ramo principale del repository. Spesso negli ambienti agili lo sviluppo branch-based viene affiancato da una tecnica chiamata Continuous Integration. I benefici principali ottenibili riguardano appunto l'integrazione tra diverse componenti del software, che possono essere sviluppate indipendentemente da più gruppi diversi, che utilizzano le ultime versioni disponibili senza preoccuparsi di eventuali bachi nei componenti usati in quanto ciascun albero è garantito essere funzionante in ogni momento. Questo permette di ridurre drasticamente i tempi di integrazione mentre ci si avvicina al rilascio e riduce notevolmente il numero di bachi grazie alla continua osservazione dello stato funzionale dei componenti e del sistema nel suo complesso. È facile comprendere come l'uso di ciascuna di queste tecniche permette di aumentare la qualità del software che sviluppiamo e di ridurre i momenti di panico dovuti a bachi estremamente difficili da trovare e quindi correggere.

Per fornire queste possibilità il modello tende a creare nuovi rami di sviluppo, i cosidetti branch, per sviluppare nuove funzionalità o correggere bachi esistenti, e una volta terminato il lavoro si prosegue a riunire i due rami attraverso l’operazione di merging.

Nei sistemi centralizzati come Subversion si cerca di ottenere questa funzionalità strutturando l’albero in almeno 2 sottodirectory e usando il comando di copia come comando di branch. Come conseguenza di questo, si ottiene una fisionomia dei repository che può essere spesso ricondotta alle seguenti 3 directory:

trunk/
branches/
tags/

Nel momento in cui lo sviluppatore intende lavorare a una nuova funzionalità, crea una copia dell’ultima versione del repository, presente in trunk, ad esempio nella directory branches/new_cool_feature e prosegue quindi il suo lavoro in questo nuovo branch.

Nei sistemi distribuiti come Mercurial si procederebbe creando una copia dell’albero di riferimento, lavorando quindi su di essa e procedendo nel push dei changeset interessati verso l’albero di riferimento.

Vi sarete accorti della pochissima differenza presente tra il modello di sviluppo centralizzato e questo modello per quanto riguarda i sistemi distribuiti. In realtà non c’è nessun problema in questo poiché i moderni DVCS sono stati creati proprio pensando allo sviluppo branch-based rendendolo, di fatto, uguale allo sviluppo centralizzato.

Si potrebbe pensare che, comunque stiano le cose, non ci sia una grande differenza neanche tra i sistemi distribuiti e quelli centralizzati. In realtà però le differenze sono molto grosse e non subito evidenti.

Nei log dei sistemi distribuiti, fino al momento del merge, non vi è traccia dei cambiamenti avvenuti nel branch. Si tratta di un cambiamento positivo in quanto permette di tracciare una chiara linea di demarcazione tra i cambiamenti che appartengono a un ben determinato branch e quelli dell’albero principale. Sebbene inizialmente possa sembrare poco utile, non si può non notare come in realtà lo diventi nonappena si procede alla ricerca dei commit riguardanti una data funzionalità. Se questa è stata sviluppata in un branch, in un sistema centralizzato il risultato che otterremo sarà un’inversione temporale dei log, che quindi non saranno più correttamente ordinati considerando il momento del merge come momento iniziale dell’introduzione della nuova funzionalità, saranno invece mischiati temporalmente agli altri log ottenuti durante lo sviluppo di altri branch o del ramo principale. Questo aumenta la confusione e diminuisce drasticamente l’utilità dei log.

Un’ulteriore differenziazione, e questa di origine molto pratica, è la possibilità di eseguire con grande semplicità il cosiddetto merge forward. Capita praticamente sempre infatti che dopo la creazione di un branch, un altro venga unito nuovamente con il ramo principale e, nel caso di branch dalla vita molto lunga, possono capitare anche più fusioni tra branch. Per gestire questo tipo di necessità nei sistemi centralizzati bisogna ricorrere a strumenti di terze parti e/o al lavoro manuale di risoluzione dei conflitti tramite patch. Nei sistemi distribuiti invece basta eseguire un nuovo comando di aggiornamento dell’albero locale con l’albero remoto. Tutta la storia locale verrebbe fusa con quella principale (anche se non necessariamente, posso fondere con la stessa semplicità anche due branch distinti) sfruttando algoritmi estremamente sofisticati o strumenti esterni installati sul sistema in uso. In questa situazione, un ulteriore vantaggio dei sistemi distribuiti è, ancora una volta, la chiara separazione tra albero principale e alberi secondari relegando gli eventuali problemi al branch in sviluppo piuttosto che all’albero principale che deve rimanere relativamente stabile.

Sviluppo di software customizzati

Figura 3. È possibile creare branch isolati e customizzati per ciascuno dei nostri clienti continuando a sviluppare il ramo principale e importanto solo i cambiamenti interessanti negli alberi specializzati.

Sull’onda del secondo modello analizzato arriva lo sviluppo di un software che viene poi adattato per ciascuno dei nostri clienti, anche solo perché vengono cambiati leggermente alcuni degli algoritmi implementati o i temi e i layout grafici. È immediata l’osservazione che riguarda la possibilità di isolare totalmente i singoli clienti (senza mantenerli nello stesso albero, magari dentro la directory branches/) mantenendo però un singolo albero principale, uguale per tutti, su cui avverrebbe lo sviluppo comune.

La semplicità di gestione del merge forward e la totale separazione dei branch rende gli strumenti distribuiti quelli più adatti a questo genere di situazioni lavorative.

Backport di funzionalità

Ancora una volta la semplicità di esecuzione del merge forward ci permette di avere alcune revision dei nostri software, anche chiamate tag, che vengono congelate in quanto rappresentano punti di riferimento nella storia di quel software. Capita spesso però di trovare problemi di sicurezza durante lo sviluppo e sarebbe estremamente utile avere la possibilità di aggiungere un tale update anche alle vecchie versioni rilasciate dei nostri prodotti. Nei sistemi distribuiti il problema viene semplicemente ridotto alla copia dei changeset interessanti per il fix all’interno dell’albero contenente il tag. Così facendo abbiamo aggiornato i nostri tag con le ultime patch di sicurezza e possiamo quindi aggiornare i software vecchi con il minimo sforzo. Nei sistemi centralizzati invece è richiesto un lavoro più complesso di estrazione del cambiamento, specialmente se consistente in più commit, e nell’integrazione dello stesso nel tag.

Esternamente a tutti e 4 i modelli vanno fatte notare ulteriori caratteristiche.

Soltanto gli utenti autorizzati possono eseguire un’operazione di push (spostamento dei changeset da locale a remoto), significa quindi che nel caso in cui uno sviluppatore non avesse tali permessi non sarebbe possibile proseguire in questa operazione ma sarebbe possibile procedere solo con l’aggiornamento del server con il repository remoto, eseguita da chi ha sufficienti permessi e che quindi può decidere se e come proseguire nel merge avendo pieno controllo sull’albero principale. Al limite estremo l’albero principale potrebbe essere accessibile solo allo sviluppatore principale o al responsabile del progetto che deciderebbe autonomamente quando e come unire le funzionalità sviluppate nei branch dei singoli sviluppatori.

Ciascun branch creato può quindi essere messo a disposizione del resto del mondo attraverso uno dei protocolli supportati dal software che decidiamo di usare, permettendo ai manutentori del progetto, su cui non abbiamo sufficienti permessi, di aggiornare i loro repository con i nostri cambiamenti, o addirittura ad aggiornare l’albero principale con i bugfix e le nuove funzionalità presenti nei repository dei membri della community.