Uno schermo che fa la differenza: quello di Jenkins

Capita di portare avanti un progetto con molte persone, parliamo di 6/7 persone, che magari sono distribuite in differenti team di lavoro (frontend/backend) e che per rendere le cose più semplici ( si fa per dire ) sono anche dislocate in diversi settori dell’ufficio. In questo contesto, quando i  tempi stringono ed è necessario tenere tutto sotto controllo, è molto produttivo mettere in piedi un sistema di continuous integration (da qui in poi CI) che sia in grado di stabilire quando c’è qualcosa che non va nell’eseguire la suite di test.

Bene, non è la prima volta che parlo di CI e soprattutto non è la prima volta che la metto in pratica per un progetto delicato. Ma questa volta c’è qualcosa di diverso, qualcosa di semplice, una mossa in più (anzi, due) che cambia tutto.

I risultati migliori si hanno sempre per caso e così anche questa volta. È un caso che abbia una macchina inutilizzata, ma sempre pronta, sempre connessa. E allora l’idea: la macchina è accesa, tanto vale farne un’utilizzo.

Colleghiamoci uno schermo per mostrare una sola ed unica cosa: il monitor di jenkins.

Il monitor di jenkins non è nient’altro che una schermata full screen che mostra il risultato dell’esecuzione della suite di test. Di monitor vecchi ce ne sono tanti basta trovarne uno funzionante in magazzino ed il gioco è fatto. In poco tempo sulla mia scrivania c’e un monitor in più, verde o rosso a seconda dello stato del progetto. Basta un colpo d’occhio ed è facile capire se le varie persone del team hanno introdotto bug o errori di regressione.

Monitor dedicato a Jenkins
Monitor dedicato a Jenkins

Ora, prima di questa volta, Jenkins eseguiva le sue verifiche in modalità temporizzata. Il che significava 2/3 volte al giorno pianificate da un cron Job. Da qui l’altro passo:

invece di renderlo temporizzato, facciamolo partire subito dopo che il sistema di versionamento (svn, git) ha ricevuto un commit.

Ecco che un sistema, che nasce così senza molte pretese, cambia completamente l’approccio. Ora, ogni volta che qualcuno esegue un commit, Jenkins non solo si mette al lavoro, ma il risultato è li a portata di mano. Quando lo schermo diventa rosso il riscontro è inevitabile.

Prima di posizionare un monitor, veniva semplicemente inviata una mail con la consapevolezza di non avere un riscontro live, soprattutto quando si è immersi nel lavoro. Il rischio è che i componenti del team, ignari (ma non assolvibili) dei failed-test, potrebbero procedere nel lavoro, o peggio passare ad altro, senza essersi resi conto che le modifiche appena apportate hanno scaturito degli errori. Il vantaggio sta proprio nell’avere un’informazione invasiva (come dice Jacopo). Il monitor è diventato rosso, è inevitabile ignorarlo. Cercando i dettagli della build, è possibile individuare l’autore del commit in fail e i test che sono falliti. Di conseguenza diventa più facile risolvere i problemi generati senza ulteriori propagazioni. L’utilità aggiuntiva dello schermo, è diventata un must senza la quale ora mi sembra impossibile pensare al work flow del passato.

Perché se come è vero che l’obiettivo della CI è scoprire i problemi il prima possibile, in pieno stile Agile, l’utilizzo di questi due accorgimenti ci permetterà di farlo ancora prima.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...