Integrazione continua

Il cliente si accorge di aver sbagliato requisiti e cambia le carte in tavola a progetto avviato? È come decidere di cambiare il pilone portante di un grattacielo mentre state decorando il cinquantaquattresimo piano.

Il progetto è una mangrovia di librerie esterne. Vi fidate di sconosciuti colleghi in giro per il mondo. Ad un tratto qualcosa non funziona secondo documentazione e per il capo è comunque tutta colpa vostra.

Siete in molti a condividere la cartella di progetto? Un membro del team potrebbe amare sovrascrivere/obliterare file scelti dal destino.

Il capo vuole assolutamente collaudare l’avanzamento del progetto a granularità superfine? A volte è come chiedere di assaggiare una torta ogni sessanta secondi durante la cottura, rovinando intenzioni e risultato.

Per il tester, il lavoro sul modulo A non va rifatto durante il check-up del modulo B; il lead developer vorrebbe che il codice del modulo B non fosse ridondante del modulo A. Uno dei due potrebbe restare deluso.

Che cosa possiamo fare

Prima di tutto bisogna favorire l’ordine, o meglio alimentare la fiducia nell’ambiente di sviluppo. Per ambiente non intendo l’Integrated Development Environment, ma proprio il concetto allargato di dove e come intrecciare il tessuto lavorativo: dall’asilo nido (dove far nascere e svezzare l’applicazione) al sistema previdenziale virtuale (con quale dovremo poi dare supporto durante tutto il ciclo di vita del software).

Il buon lavoro del programmatore dipende dall’IDE (qui Wingware) ma non solo.

Esistono diverse buone pratiche. Al netto dell’uso di un repository CVS (di cui abbiamo già parlato in questo articolo) le altre sono tutte soluzioni indipendenti tra loro ma che si intrecciano come a suggerirci che sia comunque una buona idea valutarle tutte.

Aiutarsi con il bug tracking

Ricordarsi dove sono sono tutti i graffi sulla carrozzeria della nostra auto potrebbe essere difficile; ricordarsi che l’auto non parte perché la batteria è scarica, invece, no. In entrambi i casi sarebbe buona cosa segnare da qualche parte che i difetti correnti sono segnati qui mentre i problemi attualmente riscontrabili invece sono segnati lì.

Tramite un sistema di bug tracking è possibile non sono tenere traccia dei difetti, ma assegnare tramite un sistema di ticketing la risoluzione degli stessi ai colleghi d’ufficio.

Risultato? Una To-Do list pronta quando si entra in ufficio, un posto dove appuntare le prossime cose da fare prima di lasciarsi la giornata lavorativa alle spalle ed un modo migliore per far sapere ai colleghi chi attualmente maneggia la patata bollente.

Integrare a ritmo serrato

Combinare gli aggiornamenti dei diversi moduli dell’applicazione (o anche solo tenerne sotto controllo gli avanzamenti) può rivelarsi un compito difficile senza lo strumento adatto. Grazie al repository CVS possiamo comunque inviare al sistema tutte le operazioni rendendole immediatamente disponibili ai responsabili dell’integrazione dei diversi moduli, senza per questo consentire loro di rinunciare alla possibilità di fare un passo indietro se necessario.

Automatizzare le build

Perché aspettare per controllare che la nostra ultima modifica non renda inservibile l’intero progetto, magari per colpa di un effetto imprevisto all’interno del codice di un collega?

Jenkins: server open source per l’automazione.

È possibile delegare una macchina/servizio (per esempio Jenkins) che verifichi lo stato dell’arte del codice mediante un checkout dal repository, avvii il processo di compilazione e registri di volta in volta l’output. Una sirena potrebbe avvertirci che al minuto X, dopo aver aggiunto le modifiche di Tizio e Caio, il progetto non compila più. Troppo crudele?

Auto-testare le build

Un codice compilabile ed eseguibile non è necessariamente corretto a livello funzionale. Progettare una serie di test automatici sul prodotto compilato (magari aiutandosi con un servizio creato ad hoc) consentirebbe di garantire la solidità delle procedure implementate ad ogni build (magari automatica).

Immaginate l’insieme completo di tutte le tecniche sopra esposte: vi mettete al lavoro, scaricate gli ultimi aggiornamenti al progetto dei colleghi sulla vostra workstation e pescate dalla lista di ticket il prossimo compito. Concluso lo sviluppo/bugfix, potete inviare la vostra soluzione avviando automaticamente la compilazione di nuova build. Se la build avrà successo verrà sottoposta al set di test funzionali automatici che, se andranno a loro volta a buon fine, risulteranno in un archivio che potrà essere lavorato, impacchettato e decorato con un changelog ed una feature list deducibile dai ticket chiusi e dalle milestone raggiunte.

Guglielmo di Occam diceva Non complicate le cose se non è necessario, ma qui sta a voi decidere.