Due strumenti fondamentali: Test e CI/CD

Tutti sanno che, se si sta attenti alle lezioni, lo studio che segue sarà più semplice e richiederà meno tempo… quanti però riescono con costanza a metterlo in pratica?
Oggi si affronta una di quelle tematiche, di quelle best practice, che ogni “buon” sviluppatore conosce ma che spesso viene rimandata / esclusa dalla nostra quotidianità: Unit Test e Continuous Integration/Continuous Delivery.

Nel mio passato da “Startupper” mi sono spesso, per non dire sempre, trovato a dover programmare in condizioni difficili; tempistiche molto stringenti, continui cambi di direzione e richieste assurde da parte di investitori e clienti (per chi lì ha) sono il pane quotidiano di un programmatore all’interno di una Start up, soprattutto nelle primissime fasi in cui il prodotto che si vuole lanciare sul mercato non è ancora ben definito.

Questi fattori spingono gli sviluppatori a produrre codice con scarsa attenzione, di fretta, in assurde sessioni notturne prima di un particolare evento (chi ha il mio stesso background capirà di cosa parlo), trovandosi in estrema sintesi a non poter utilizzare tutte le “best practices” del caso, anche se ampiamente conosciute e studiate.
Personalmente mi sono trovato più volte a dover saltare la fase di testing del codice o la scrittura degli Unit Test (https://it.wikipedia.org/wiki/Unit_testing) proprio perché inseguito dalle scadenze o dall’incombere di nuove task, oppure ancora a dover effettuare deploy manuali del codice sui server di testing e/o produzione impiegando un effort inutile.

Oggi, raggiunta una maturità aziendale maggiore, la mia vita è decisamente più serena, così come il mio codice, e non ho più scuse per rinunciare a questi due strumenti importantissimi che, seppur richiedono maggior effort e tempo nell’ inizializzazione di un nuovo progetto, migliorano a lungo andare la qualità del codice e più in generale la manutenibilità e consegna di release sempre più solide.

In generale se volessimo puntualizzare e definire dei miglioramenti reali che questi due strumenti apportano al nostro codice, degli Unit Test possiamo sicuramente dire che:

• Lo unit testing facilità allo sviluppatore la modifica di moduli e più in generale il processo di Refactoring del codice. Grazie ai test infatti possiamo tranquillamente “rifattorizzare” il nostro codice avendo la sicurezza alla fine di questo processo che tutto il sistema funzioni e risponda in modo identico a prima del Refactoring.
  Questo vantaggio non è affatto banale soprattutto se lavoriamo con applicazioni modulari e in cui gli output di un modulo sono poi l’ingresso di un altro e inducono una serie di reazioni a catena.
  In questi tipi di applicazioni non vogliamo che una disattenzione durante il refactoring o bugfixing ci porti a uno stravolgimento del flusso applicativo.
• Lo unit testing educa il programmatore al principio di separazione tra interfaccia e implementazione.
  Mi spiego meglio, l’unit test è appunto per sua natura un test su una unità singola e indipendente che spesso viene identificata con una classe.
  In questo modo il programmatore quando scrive gli unit test riesce a comprendere se l’unità che sta testando è ben isolata o se il test varca questo sottile confine e sfocia nel campo di un’altra unità.
  In questo caso si deve ripensare il test per far si che sia il più mirato possibile.

Il testing come processo generale diventa poi una fase di quella che viene denominata CI/CD e cioè una procedura di “continua integrazione” del codice in una repository considivisa (CI) a cui aggiungiamo un processo di “continua consegna” del codice in produzione (CD).

Questo processo viene gestito ormai da innumerevoli tool che ci aiutano e semplificano il lavoro per far si che la pipeline di consegna sia il più semplice e performante possibile.
Quello che attualmente preferisco utilizzare è la CI/CD di Gitlab che ritengo sia un utilissimo strumento integrato all’interno del servizio che Gitlab offre e che ci permette di gestire il tutto nella stessa piattaforma.

Le pipeline di CI/CD sono molto relative al tipo di prodotto che viene sviluppato, in agenzia siamo molto orientati al Web e al Mobile quindi quello che sviluppiamo per buona parte del tempo sono prodotti come Web App, API Rest, applicazioni native per iOS e Android.
Per esempio per un tipo di prodotto orientato al Web una pipeline base di CI/CD ha 3 step fondamentali che iniziano la loro esecuzione dopo un commit in repository.

Step 1 Build
Una fase in cui tramite gli strumenti relativi al freamework utilizzato il codice viene compilato e viene generata una cosiddetta “build” che sarà poi quella pubblicata sul nostro server.

Step 2 Test
Una fase, ampiamente discussa in precedenza, in cui alla realese sottoposta alla pipeline vengono eseguiti i test, non per forza esclusivamente Unit Test ma qualsiasi tipo di processo di testing automatico che può attuarsi a un software.

Step 3 Deploy
La fase finale in cui la nostra release dopo essere stata compilata e testata se ha superato con successo tutti gli step precedenti viene pubblicata sul server stabilito in base al branch in cui il commit è stato effettuato.

In conclusione possiamo dire che mentre il testing è un processo che deve essere seguito e implementato dai programmatori durante la fase di sviluppo del codice, l’implementazione di una pipeline di CI/CD invece non compete ai programmatori ma alla figura sempre più presente in ogni azienda dei DevOps.
Tutti e due questi strumenti però, talvolta ignorati o sottovalutati, possono aiutarci nella vita di tutti i giorni in modo veramente consistente permettendoci uno di scovare bugs e di migliorare la scrittura del nostro codice e l’altro invece nella consegna del codice scritto in precedenza in maniera più efficiente e veloce.

In sintesi, tutti sappiamo cosa sarebbe meglio fare, ora sta a noi però sforzarci di metterlo in pratica ogni giorno!