Riflessioni sui trend nei sistemi di gestione del codice sorgente

  • Article

Questo post rappresenta alcune riflessioni sull’evoluzione dei sistemi di gestione del codice sorgente, derivate da una serie di eventi:

E ora, dopo questa lunga introduzione e questa serie di link… ecco cosa penso:

Prima di tutto bisogna distinguere fra sistemi di versionamento e sistemi integrati per la gestione dell’Application Lifecycle Management (ALM) .

  • I primi si occupano solo di gestione del codice sorgente, e sono eventualmente integrabili con altri sistemi separati, bisogna gestirne l’evoluzione, etc… etc…
  • I secondi cercano di coprire tutto il ciclo di vita del software, dall’inizio (definizione dello scope dei progetti) alla fine (deployment), e oltre (manutenzione) (per maggiori info vi rimando ai video dell’ALM Day su BE IT).

I DVCS si posizionano generalmente nella prima categoria, e sono la soluzione migliore quando le persone devono lavorare separatamente, non hanno bisogno di tool totalmente integrati, oppure quando lavorano in modalità quasi completamente disconnessa (cosa valida per moltissimi progetti Open Source e per alcuni progetti/realtà aziendali).

I sistemi di gestione dell’ALM cercano di risolvere un altro problema, ovvero la gestione, la tracciabilità, la pianificazione, le build, il deploy, etc… in maniera tipicamente centralizzata e controllata. O almeno questo è quello a cui tendono i vari strumenti, ma non è detto che i team riescano (per vari motivi, dalla vera necessità alla capacità di implementare un processo) a ottenere tutti questi risultati.

Tipicamente gli sviluppatori tendono ad apprezzare la “libertà” fornita da un DVCS, mentre i responsabili ed in generale le organizzazioni tendono ad apprezzare il “controllo” fornito da un sistema integrato di ALM.

Gli sviluppatori “pigri” poi, preferirebbero non avere neanche un sistema di gestione del codice di nessun tipo… tanto basta fare un backup ogni tanto… ma di solito questi hanno vita “professionale” breve e travagliata…

Ah… naturalmente c’è chi preferisce lavorare con l’integrazione nell’ambiente di sviluppo, chi da command line, e chi con l’integrazione con l’esplora risorse… ma quelli sono gusti… l’importante è che lo strumento scelto supporti il proprio modo di lavorare…

 

E i sistemi di gestione del codice sorgente “tradizionali” , non distribuiti e non integrati in una soluzione di ALM? Secondo me non avranno una “lunga vita”… (naturalmente dureranno ancora anni e anni, ma saranno sempre più considerati legacy, una commodity alla quale prima o poi bisognerà mettere mano…) visto che vengono sempre più “attaccati” da un lato e dall’altro.

 

In questo momento (come molto spesso accade nel mondo dell’informatica) c’è una diatriba tra i sostenitori dei vari schieramenti, i confini tra gli strumenti tendono ad essere in parte netti (o centralizzato o distribuito) e in parte “fumosi” (tentativi di “estendere” verso il modello distribuito sistemi monolitici, e di integrare in soluzioni di ALM i sistemi distribuiti). C’è chi vive il tutto come una battaglia, e chi (come il team di CodePlex) cerca di fornire lo strumento giusto agli utenti che ne fanno richiesta. Dopotutto non tutti i progetti “nascono” distribuiti e non tutti necessitano di soluzioni ALM complete.

 

Una piccola digressione… TFS e il “mondo” distribuito

Il post di Brian Harry fa riferimento ad evoluzioni future di TFS (post TFS 2010) che supporteranno meglio le problematiche degli sviluppatori che devono lavorare “isolati”, magari offline, e che oggi prediligono i DVCS. Naturalmente ottenere queste funzionalità e nel contempo riuscire ad evolvere per soddisfare meglio le esigenze “tradizionali” degli utenti ALM non sarà facile, ma la strada è tracciata.

In questo momento però è già possibile fare delle scelte basate su TFS e affrontare il “mondo” distribuito, senza aspettare una futura versione. L’introduzione di TFS in modalità “Basic”, i cambiamenti del licensing di MSDN (ogni utente che ha un abbonamento  MSDN ha una licenza di TFS), e il miglioramento continuo della TFS Integration Platform permettono già oggi di lavorare in una modalità “simil” distribuita. Ovvero, si può mettere un TFS centralizzato, installare un TFS (full o basic a seconda del sistema operativo) nelle macchine di chi ha bisogno dell’utilizzo distribuito, e poi si possono configurare delle branch per le persone “distribuite”, branch che verranno sincronizzate tra le due istanze dei TFS (centrale e locale) per i vari utenti (ognuno con la sua branch e il suo TFS).

A quel punto, l’operazione di “push” dal repository che si effettua con un DVCS viene sostituita dalla sincronizzazione della branch unita ad una successiva operazione di merge dei sorgenti nel sistema principale. Se si lavora bene, l’effort speso nei due casi è molto simile, anche se nel caso del TFS si deve configurare e gestire più di un sistema. Come scritto prima però, la strada è tracciata…

In alternativa, per supportare scenari più semplici, c’è sempre la possibilità di adottare il TFS in scenari disconnessi, come mostrato in questi articoli relativi a TFS 2008 (prima parte, seconda parte, terza parte). Dopo l’uscita di TFS 2010 li aggiornerò con le ultime novità e con i nuovi strumenti.

Conclusioni

Non ce ne sono… smile_regular

A parte gli scherzi, è interessante vedere l’evoluzione e la concorrenza tra i vari strumenti, che porta ad una crescita per tutto il settore, ed ad un miglioramento della qualità del lavoro delle persone.

E, per la scelta fra DVCS, VCS e ALM, ognuno prenderà la strada che più preferisce… il mio consiglio è di farlo valutando la propria capacità di gestire il processo che si mette in campo, e poi lo strumento, scegliendone uno che “abiliti” al meglio il proprio processo.

-Lorenzo