Modifiche in maniera esclusiva di file.

Ci troviamo sempre nell'ipotesi che un gruppo di sviluppo lavori in maniera concorrente su un insieme di sorgenti. La possibilità che più di una persona si trovi a lavorare sullo stesso file non è trascurabile. Anzi, nella pratica di tutti i giorni è un evento che capita spesso.

Cosa fare in questi casi di modifiche concorrenti allo stesso file? Alcuni sistemi di versionamento forniscono la possibilità di inibire modifiche ad un file che è sottoposto a modifiche. Questa è una politica molto conservativa che, a mio avviso, limita in maniera eccessiva i gradi di libertà di un team di sviluppo.

Può accadere che una o più persone rimangano ferme con le proprie attività, fino alla fine delle attività di chi ha bloccato per primo un file. O peggio creare un vero e proprio dead-lock: un primo programmatore ha bloccato il file1 mentre il secondo programmatore ha bloccato il file2; poi ad un certo punto il primo programmatore ha bisogno di modificare il file2, però il secondo programmatore prima di rilasciare il file2 ha bisogno di modificare il file 1.

Ma è poi così pericoloso modificare contemporaneamente lo stesso file? La pratica di tutti i giorni dice che assolutamente i problemi sono minimi. Infatti per prima cosa c'è l'esperienza e bravura del capo progetto ad assegnare i task in maniera tale da rendere minimi le sovrapposizioni. Nel caso poi di modifiche allo stesso file e molto raro che le modifiche riguardino la stessa funzione o porzione di codice. Questi sono i casi risolti agevolmente da uno strumento di fusione o merge del codice sorgente.

Meno frequentemente capita che due modifiche coinvolgano la stessa porzione di codice, in questo caso una decisione umana è necessaria. Nella maggior parte di questi casi entrambe le modifiche vanno bene, va solo scelto l'ordine esatto. Ancora una volta gli strumenti di merge ci aiutano semplificandoci le operazioni di fusione.

Quando capita che più modifiche alla stessa porzione di codice risultano non compatibili, vuol dire che qualche cosa nel processo di gestione non ha funzionato. Questo è l'unico e vero caso dove l'intervento umano è fondamentale per dirimere il conflitto.

In conclusione il consiglio finale è di favorire e controllare le modifiche concorrenti allo stesso file, in modo da rendere agile le attività di sviluppo.

Per una consulenza sul versionamento dei progetti software contattami su poderico@gmail.com.

Non rompere mai il codice versionato

Il versionamento dei codici sorgenti è probabilmente lo strumento più necessario per un team di sviluppo software, ma allo stesso tempo quello meno usato. Iniziamo con questo articolo a fornire alcuni suggerimenti sul versionamento del codice, prendendo subversion come strumento di riferimento e la mia attività professionale come base di analisi.

In una normale attività di sviluppo portata avanti da un team di persone, accade normalmente che ogni membro del team prende in carico la risoluzione di una attività, che fa avanzare lo stato generale del progetto. Quindi più attività lavorative concorrono a modificare contemporaneamente il codice sorgente.

Compito di chi gestisce il progetto è quello di assegnare i compiti in maniera tale che le attività concorrenti non vadano ad intralciarsi, l'una con l'altra. Questo però in genere non basta a rendere stagni i vari ambienti di lavoro; può infatti accadere che una modifica fatta da qualcuno possa interferire con le attività di qualcun altro.

Per questo la pratica consigliata è quella di effettuare con la frequenza più alta possibile il ciclo “code, test, update, test, commit”. Ovvero effettuare un insieme di modifiche, testarle, aggiornare la propria copia locale dei sorgenti con l'ultima versione presente nel sistema di versionamento, rilanciare i test, se non ci sono fallimenti aggiornare il codice versionato con le proprie modifiche.

Le due fasi di test sono importantissime perché aiutano a non mettere sotto configurazione un codice che non funziona o peggio non compila. Non è richiesto che al commit venga sottomesso il codice che risolva il compito assegnato; l'importante è che il codice non venga rotto, ovvero che continui a compilare e a fare le cose che faceva prima nella maniera attesa.

In alcuni casi reali ho anche sentito di piccoli espedienti che aiutano al rispetto di questa regola. Ad esempio, chi rompe il codice esegue ogni sera, prima di lasciare il lavoro, un check-out dell'intero progetto, lo compila e stila un report sui test automatici. Oppure, ogni volta che viene rotto il codice sorgente si paga un pegno di un euro, che finisce in un salvadanaio che finanzia una qualche attività di socializzazione extra lavorativa.

Per una consulenza sul versionamento dei progetti software contattami su poderico@gmail.com.