Continuous Delivery: sviluppo di software tramite pipeline
La Continuous Delivery (in italiano “consegna continua”) è un concetto innovativo dello sviluppo dei software sempre più popolare. Secondo la Continuous Delivery le fasi di produzione, sviluppo, controllo qualità e rilascio non sono fini a sé stesse, ma si ripetono continuamente e in automatico nel processo di sviluppo all’interno della cosiddetta pipeline di Continuous Delivery. Il vantaggio è che i prodotti software vengono sottoposti al controllo qualità a intervalli regolari e possono già essere rilasciati mentre il prodotto è ancora in lavorazione. Nella pipeline si ricevono quindi costantemente dei feedback grazie ai quali è possibile apportare qualsiasi modifica al codice sorgente e migliorare così il software in maniera mirata.
La Continuous Delivery è un modello introdotto nello sviluppo di software per eseguire contemporaneamente le fasi di sviluppo, rilascio, feedback e gestione della qualità in brevi intervalli e in un ciclo continuo. Lo sviluppo in questo modo diventa più efficiente e il cliente riceve prima il prodotto, anche quando questo non è ancora pronto. La Continuous Delivery fornisce feedback allo sviluppatore sulla base di test automatizzati che controllano principalmente il build ogniqualvolta viene modificato il codice sorgente.
La Continuous Delivery descrive dunque un processo che unisce e automatizza sviluppo, rilascio, feedback e gestione qualità, riducendo al minimo quelle complicate fasi di lavoro che richiedono tempo.
I vantaggi della Continuous Delivery
Secondo lo sviluppo software classico, il prodotto finale viene rilasciato non appena contiene tutte le caratteristiche richieste, funziona bene e non risultano gravi difetti dal controllo qualità. Lo sviluppatore di solito prevede patch e aggiornamenti del software a intervalli più o meno regolari. Grazie alla Continuous Delivery il prodotto viene rilasciato già nelle prime fasi di sviluppo, mentre è ancora in elaborazione. La bozza prevede spesso solo le funzioni di base del software, che vengono poi testate dal cliente in un ambiente reale. Il cliente (e chi testa il software per lui) gioca dunque un ruolo fondamentale nel controllo qualità.
Il feedback che ne deriva aiuta lo sviluppatore a migliorare le caratteristiche del programma durante lo sviluppo, ricevendo possibilmente importanti indicazioni su quale deve essere l’aspetto successivo da sviluppare. In assenza della Continuous Delivery, questo processo risulta piuttosto faticoso e può portare malumori da entrambe le parti: il cliente aspetta un prodotto finito che soddisfi le sue esigenze e i suoi desideri; lo sviluppatore dall’altra parte non sa ancora in cosa esso consista esattamente. Se la comunicazione sullo stato dello sviluppo del prodotto avviene già durante le prime fasi di lavoro, è più facile tenere in considerazione i desideri del cliente ed evitare errori. Tale principio può essere rappresentato come un ciclo:
Le tre fasi di sviluppo, controllo e produzione non si estinguono in un unico processo, ma sono costantemente interconnesse tra loro: il prodotto quindi attraversa continuamente queste singole fasi e viene sempre migliorato. Con un gran numero di clienti non si può più fare a meno dell’automatizzazione: ed è qui che si inserisce la Continuous Delivery, che automatizza l’intero processo.
Grazie alla Continuous Delivery è possibile testare in tempo reale ogni elaborazione ed estensione del software (praticamente ogni modifica apportata al codice sorgente), raccogliendo così feedback costanti, utili a individuare i problemi e risolverli già nelle prime fasi di sviluppo. Un sistema molto pratico per stabilire in modo tempestivo quale parte del codice ha causato un bug: senza la Continuous Delivery la ricerca del problema potrebbe diventare davvero dispendiosa.
Prima del rilascio al cliente, il software attraversa nel suo stadio intermedio la pipeline di Continuous Delivery: in questa fase vengono effettuati test sia automatici che manuali. Ogni fase di test prevede una nuova versione del software (per lo più definita come “versione beta”, a volte anche come “nightly build”, cioè una versione generata durante la nottata) che passa attraverso la pipeline. Solo quando tutti i test sono stati superati con un feedback positivo viene creata una versione “stabile” (“stable”) e il prodotto viene ufficialmente pubblicato (questo processo come anche la stessa applicazione rilasciata viene chiamato “release”). La probabilità che il cliente riceva un prodotto senza errori è molto alta.
Il grosso vantaggio della Continuous Delivery è che conviene sia al cliente che allo sviluppatore: il cliente riceve il prodotto più in fretta e di regola senza errori, lo sviluppatore effettua dei “test sul campo” che sono molto più attendibili dei test beta effettuati in azienda, in quanto forniscono dati e indicazioni preziosi. Il completo processo di sviluppo diventa molto più flessibile e il rischio di pubblicare un software con degli errori viene ridotto al minimo.
Panoramica dei vantaggi e degli svantaggi della Continuous Delivery
| Vantaggi | Svantaggi |
|---|---|
| Gli errori di software vengono riconosciuti e risolti in modo efficiente già durante il processo di sviluppo. | Costi: è necessario un server di integrazione veloce e affidabile per effettuare test automatici e per un rilascio convincente e affidabile del prodotto. |
| Gli sforzi collegati a un release classico del software vengono meno. Lo sviluppatore può concentrarsi del tutto sul mero sviluppo del prodotto. | I test automatici devono funzionare perfettamente. I test sbagliati possono causare dei grossi danni nella fase del controllo qualità. |
| La pipeline di Continuous Delivery alleggerisce enormemente il lavoro degli sviluppatori nella ricerca degli errori. | Necessita di una buona sintonia all’interno del team in quanto le modifiche del codice devono essere effettuate spesso e in modo efficiente. |
| Non comporta costi eccessivi, evitando quei costi che deriverebbero invece da altri processi di test (ad esempio alpha e beta test). | Necessita continuamente di una buona interazione con i clienti e con i loro sistemi. |
| Il controllo qualità può concentrarsi di più sui miglioramenti progettuali che su quelli tecnici del software. | Il cliente si aspetta continui aggiornamenti e miglioramenti. Raramente sarà possibile “mettere in pausa” il progetto del software. |
| Lo sviluppo del software avviene velocemente, dato che lo sviluppatore sarà sostituito in gran parte dal processo automatizzato di release, prevedendo meno pause. | L’implementazione di novità, miglioramenti e cambiamenti al prodotto avviene ancora manualmente. Per automatizzare questo processo bisogna passare al Continuous Deployment. |
| I release veloci e frequenti accelerano i feedback e i miglioramenti. | Il cliente si deve mostrare pronto a utilizzare un software che si trova ancora in fase di sviluppo. Inoltre deve essere motivato a inviare feedback, fondamentali per la buona riuscita del progetto. |
| Lo sviluppatore subisce meno pressione in fase di cambiamento al codice sorgente, perché gli errori vengono trovati velocemente. Ciò ha un buon influsso sul lavoro, rendendolo più motivante e portando ispirazione. |
Le fasi della pipeline di Continuous Delivery
Con la modifica del codice si attiva la pipeline di Continuous Delivery e viene eseguito il processo di test. Di seguito le fasi che percorre la pipeline di Continuous Delivery:
- Commit Stage: in questa prima fase di test la versione del software viene provata, le componenti di software compilate e necessari test di unità eseguiti. Dopo che i test si sono conclusi con buon esito, questa fase è terminata. Gli artefatti binari delle componenti di software vengono raggruppati in bundle e archiviati in repository. Questo pacchetto è determinante per la funzionalità della pipeline perché indica lo stato del software: il pacchetto contiene la quantità di dati che in seguito sarà installata sul sistema finale. I risultati dei test nel Commit Stage possono quindi essere assegnati alle modifiche specifiche del codice sorgente: ciò rappresenta il vantaggio significativo della Continuous Delivery.
- Acceptance Test Stage: in questa seconda fase di test avvengono i test di accettazione, tra cui i test di integrazione (funziona l’interazione tra le componenti?) e gli importanti test di sistema (funziona il software sul sito utente?). Inoltre ci sono test opzionali che possono essere integrati all’Acceptance Test Stage, come i test di prestazione e altri test che controllano i requisiti non funzionali del software. Per l’Acceptance Test Stage si utilizzano ancora i bundle della fase precedente installati in un ambiente test adatto.
- Gli eventuali errori o le complicazioni che si registrano in queste fasi vengono documentate e, se necessario, inviate allo sviluppatore come feedback, via e-mail, programmi di messaggistica o tramite tool speciali (vedi sotto). Le segnalazioni di errore o le regressioni si riferiscono sempre all’ultima modifica, in quanto la pipeline si attiva ad ogni modifica del codice. Quindi lo sviluppatore può reagire velocemente per correggere errori o per ritoccare i codici errati.
- All’occorrenza vengono eseguiti anche test manuali. Anche per questi test la pipeline si serve del bundle della prima fase e lo installa in un ambiente test adatto.
- Se i test si concludono tutti con esito positivo, il pacchetto può essere installato manualmente sul sistema di destinazione: per farlo di solito c’è bisogno semplicemente di “premere un pulsante”. Se anche questa fase è automatizzata si parla di Continuous Deployment.
Continuous Integration e Continuous Delivery
Associato alla Continuous Delivery viene spesso utilizzato il concetto di Continuous Integration. Tuttavia c’è una grande differenza tra le due: mentre la Continuous Integration prevede l’automatizzazione dei processi di test e condivide per la maggior parte la pipeline con la Continuous Delivery, il concetto di Continuous Delivery è più esteso e prevede anche il processo di release automatizzato del software. In questo modo la Continuous Delivery integra il modello della Continuous Integration per l’utente finale, rilasciando il prodotto già nella fase di test.
Se uno sviluppatore utilizza la Continuous Integration o se estende il processo di sviluppo alla Continuous Delivery, dipende dalla pianificazione dello sviluppo, dal team di sviluppo e dal cliente. Qui di seguito le mettiamo a confronto:
| Continuous Integration (CI) | Continuous Delivery (CD) |
|---|---|
| Processo di test automatizzato che controlla in modo critico tutte le modifiche del codice sorgente. | Amplia il processo di test integrandovi il processo di rilascio. Novità e modifiche del codice arrivano automaticamente all’utente finale. |
| Il team deve creare un test automatico per ogni funzionalità, ogni miglioramento e ogni cambiamento di codice. | Anche per la CD è importante che i test siano efficienti in quanto i risultati arrivano immediatamente all’utente finale. |
| Necessita di un server dedicato d’integrazione continua che controlla e utilizza i test automatici. | Anche l’installazione sul sistema di destinazione deve avvenire possibilmente in modo automatizzato con maggiori requisiti sul server. |
| Gli sviluppatori devono riunire di continuo le modifiche al codice. | Gli sviluppatori devono curare il contatto con il cliente ed essere quanto più possibile trasparenti riguardo al software. |
| Necessita di molte risorse per assicurare la qualità del prodotto in fase di rilascio. | Il dispendio di risorse diventa maggiore nella CD. Il prodotto può essere rilasciato molto prima ed essere sottoposto a un “vero” test. |
| Lo sviluppo in sé è più efficiente, ma deve essere messo in pausa spesso dai release manuali. | Può essere sviluppata ininterrottamente, in quanto il processo di release è per la maggior parte automatizzato. |
Tool conosciuti per la Continuous Delivery
Esistono diversi programmi che semplificano l’uso della Continuous Delivery. Ve li presentiamo.
Jenkins
Jenkins è un’applicazione web per l’integrazione continua di componenti per software. Jenkins, basato su linguaggio Java, necessita di un container EJB e dispone di diversi tool di build (Apache Ant, Maven/Gradle, CVS, Subversion, Git e altri) oltre ai processi di test automatici (JUnit, Emma) importanti per la Continuous Delivery. Altri plug-in in opzione assicurano la compatibilità con altri compilatori. L’interfaccia di programmazione basata su REST permette anche agli altri programmi di servirsi di Jenkins. Jenkins è un programma open source gratuito. È consigliato soprattutto per i principianti, in quanto l’interfaccia e le funzionalità sono molto semplici da usare.
Leggete il nostro tutorial di Jenkins passo per passo per capire come funziona l’applicazione.
CircleCI
CircleCI è un’altra applicazione basata su web per Continuous Integration, Delivery e Deployment. CircleCI lavora soprattutto con GitHub, GitHub Enterprise e Bitbucket. Inoltre la piattaforma offre molte funzionalità pratiche come la gestione degli incarichi, la gestione delle risorse, supporto docker, supporto di tutti i linguaggi di programmazione conosciuti, caching sicuro, analisi dei dati con statistiche e sicurezza. Nel 2017 CircleCI ha ricevuto il premio di “Leader in Continuous Integration” da Forrester. Il primo container è gratuito, a partire dal secondo il costo è di circa 45 euro per ogni container al mese.
Team Foundation Server di Microsoft
Microsoft Team Foundation Server (TFS) è un tool di collaborazione per i progetti software che devono essere pianificati, creati e infine gestiti. Il TFS è il successore non ufficiale di Microsoft Visual SourceSafe. Per lavorare insieme a diversi progetti software TFS supporta diversi processi di sviluppo, tra cui CMMI, lo sviluppo agile di software e Scrum. In fase di lavoro vengono collegati e integrati programmi Office come Word ed Excel, di modo che TFS non debba passare a un altro programma.
Sono a disposizione diverse funzionalità per Continuous Integration, Delivery e Deployment con le quali si costruisce una pipeline. TFS suddivide l’intero processo in fasi di controllo della versione, build, report e gestione utente.
I team composti da massimo 5 persone utilizzano la versione Express gratuita, i team più grandi la versione commerciale che costa circa 6 dollari per utente al mese; inoltre bisogna acquistare anche una licenza di server. È possibile acquistare anche TSF senza l’abbonamento mensile: per farlo bisogna però contattare un rivenditore locale. Il prezzo varia da 500 a 700 euro.
Codeship
Codeship è una piattaforma SaaS per la Continuous Integration (e Delivery) che si adatta completamente alle esigenze dell’utente. Codeship supporta GitLab, GitHub e Bitbucket. Le funzionalità disponibili si basano sul piano tariffario: la versione gratuita offre Codeship in un ambiente CI predefinito e il workflow che risulta da CI/CD. Inoltre la variante gratuita garantisce un caching efficiente e parallelamente dei test di build in container separati e preconfigurati. Il piano gratuito offre 100 build al mese con un build continuo e una pipeline di test. Degna di nota è la mancanza di un limite per progetti, utenti e team.
Per poter sfruttare al massimo Codeship, si può acquistare “Codeship Basic” al prezzo di 45 euro al mese, che diventa più caro a seconda della grandezza del team. La versione “Codeship Pro” aumenta le sue funzionalità con un supporto per Docker, che offre il “controllo completo” sull’ambiente build, i build locali e un miglior controllo sul workflow. Inoltre sono accessibili diversi tool per rendere la Continuous Integration/Delivery ancora più efficiente e trasparente. Codeship Pro ha un prezzo mensile di circa 70 euro che varia a seconda dei build paralleli.