Se in passato l’approccio agile era adottato dai team di software più all’avanguardia, oggi è decisamente diventato mainstream, utilizzato da molti team di sviluppo in diverse aziende – dal settore sanitario, a quello manifatturiero o ingegneristico – allo scopo di rendere i propri processi più efficaci.
L’adozione di processi agili, tuttavia, rappresenta solo una parte di una delivery del software più veloce. Quando si tratta di migliorare il modo in cui un’organizzazione utilizza il software per innovare il proprio business, la sola installazione di un nuovo strumento come Kubernetes per snellire le operazioni non porterà certo a un cambiamento radicale se le aziende non si occupano di come strutturare i processi di creazione e delivery del software.
Oggi molti progetti si sviluppano con un approccio waterfall: le caratteristiche del software sono specificate in anticipo, gli sviluppatori scrivono il codice e l’applicazione viene rilasciata agli utenti. In questo modo, le attività procedono una dopo l’altra e si rincorrono spesso a discapito del progetto.
Attenersi troppo rigidamente al processo fa sì che gli sviluppatori continuino a seguire lo stesso percorso fino alla fine, aumentando così il rischio di trovarsi dinnanzi a problemi endemici del software che avrebbero potuto essere evitati se si fossero eseguiti test più ampi e frequenti in precedenza. Fortunatamente, esistono oggi nuove pratiche di sviluppo software e strumenti che aiutano a evitare di “cadere” in questa cascata. Alcuni dei più importanti sono l’integration continua (CI) e la delivery continua (CD). Come vedremo, si tratta di strumenti fondamentali in grado di modernizzare la supply chain del software.
Continuous integration (CI) e continuous delivery (CD)
Questi strumenti, processi e policy permettono ai team di sviluppo di codificare, costruire, testare e distribuire rapidamente nuove funzionalità a cadenza settimanale, se non quotidiana. Un deploying frequente di tutto questo è la chiave per mettere in atto il ciclo di feedback necessario per iniziare a usare il software come strumento principale di innovazione di un’organizzazione.
Un recente sondaggio ha scoperto che il 46% delle organizzazioni EMEA a più alte performance (ovvero quelle con una crescita delle entrate del 15% o più) attribuiscono alla CI/CD il merito di aver supportato la propria trasformazione.
Eppure, storicamente, le organizzazioni sono state decisamente lente nell’adozione della CI/CD. Sono sicuramente stati fatti dei progressi, ma l’adozione CI/CD è ancora bassa. La recente survey sollo State of Agile di quest’anno ha evidenziato che l’adozione della CI è al 55% e quella della CD solo al 36%, percentuali rimaste costanti per molti anni, a dimostrazione di come l’adozione della CI/CD sia stagnante.
Adottare un approccio CI/CD è vitale per lo sviluppo della trasformazione digitale attraverso il software, ma con una consapevolezza da parte delle organizzazioni ancora così bassa, esploriamo cosa devono fare i team per sviluppare con successo questi processi.
Riscrivere il testing tenendo conto della propria strategia
Avere feedback veloci e concentrarsi sui requisiti anche quando questi cambiano è cruciale per il successo dell’approccio agile nei progetti. È qui che la CI/CD può offrire un enorme valore ai team che progettano software, supportando regolarmente test e integrazioni delle soluzioni per incorporare i cambiamenti man mano che avvengono. Tuttavia, la natura di un processo simile significa anche che l’adozione di un approccio CI/CD per la prima volta possa richiedere molto tempo, aprendo la strada a un intero ripensamento su come i team di software lavorano.
I team tradizionali eseguono una buona quantità di test alla fine di un progetto, e tipicamente questo avviene appena prima del deployment. Questo spinge l’effettiva verifica del software piuttosto in ritardo rispetto al processo.
Senza eseguire test fin dall’inizio, è difficile realizzare una vera CI. La CI automatizza l’esecuzione di test unitari, controllando la conformità d’uso del codice e assicurando che tutto il vostro codice funzioni nell’insieme (ed è qui che si realizza la parte di “integrazione”). Se i test sono superficiali, il valore della CI è neutralizzato.
Preparare la produzione per il deployment giornaliero
Infine, i team di sviluppo software che introducono un approccio CI/CD devono preparare i loro ambienti di produzione per gestire deployment settimanali, se non giornalieri. In caso contrario, i benefici di queste tecnologie non saranno realizzati, poiché lo scopo della CI/CD è proprio quello di offrire delivery frequenti in una serie di cicli più brevi che permettano di imparare e adattarsi man mano che si procede. L’approccio al software diventa quindi agile, non più bloccato da requisiti e piani vecchi di mesi che non sono più utili, o addirittura realistici.
Lavorando insieme, CI e CD fanno sì che ogni fase dello sviluppo non operi più in silos ma possa essere adattata man mano che si procede. Questo, a sua volta, aiuta a realizzare una comprensione più approfondita dei clienti e, di conseguenza, di come accrescere il business.
Per sviluppare software: testare (e testare ancora) per un risultato snello
Senza un test continuo e rapido del codice, sviluppare un software di qualità che sia effettivamente utile dall’inizio alla fine è molto più difficile. Mettere in atto questi processi continui e automatizzati non solo ridurrà il tempo e i costi, ma aiuterà a ottimizzare il software proprio mentre viene sviluppato. La capacità di consegnare un software più frequentemente è la chiave per poterlo utilizzare al meglio per migliorare concretamente il proprio business.
Per concludere, se non lo state già facendo, consiglio di iniziare il prima possibile ad allocare tempo e risorse per implementare una vera CI/CD perché pagherà dividendi sul lungo periodo specialmente quando si tratterà di individuare e risolvere eventuali problematiche.
