Continuous Integration, Continuous Delivery e Continuous Deployment: tre modelli di sviluppo del software a confronto

I processi di sviluppo del software sono costosi. Specialmente quando il nuovo codice non può essere integrato con facilità nel software esistente, i costi salgono alle stelle. I moderni approcci di Continuous Integration, Delivery e Deployment (traducibili in italiano come “integrazione continua”, “consegna continua” e “distribuzione continua”) forniscono un rimedio al problema. Questi modelli fanno affidamento sulla convalida multipla del codice già durante il suo sviluppo. Lavorare in diverse fasi di sviluppo più piccole permette anche di consegnare al cliente dei prototipi del prodotto desiderato. In questo modo, il cliente può aggiornare le sue richieste in fase di sviluppo e verificare di volta in volta se il software assume la forma desiderata.

I modelli moderni di sviluppo del software hanno tutti le loro origini nel concetto di sviluppo agile del software. Questo è un approccio che mira non solo ad accelerare lo sviluppo del software, ma anche a renderlo più trasparente. L’obiettivo dell’approccio agile è quello di sviluppare software di cui il cliente ha veramente bisogno. Attraverso i prototipi che vengono messi a disposizione durante tutta la fase di sviluppo, il cliente può verificare se il software fa effettivamente quello che dovrebbe fare e se è compatibile con il software preesistente. Anche i desideri dei clienti che emergono durante il processo di sviluppo possono anche essere integrati grazie ai metodi agili.

Il modello di sviluppo agile prende sempre più piede anche nell’ambito delle culture aziendali. Esistono diverse strategie per velocizzare i processi di sviluppo all’interno delle aziende. Uno di questi è DevOps. Il termine DevOps nasce dalla combinazione dei termini inglesi “Development” (sviluppo) e “Operations” (organizzazione). Lo scopo di questa cultura aziendale è quello di far sì che i team di sviluppo lavorino assieme ai team organizzativi durante tutta la fase di sviluppo di un software e oltre. Ciò permette di evitare problemi di integrazione del software fin dall’inizio e facilita il controllo e la distribuzione dei programmi finiti. Oltre allo sviluppo continuo, i rappresentanti di DevOps fanno affidamento anche su Continuous Integration e Continuous Deployment.

Il modello di Continuous Integration ha come scopo quello di rendere l’incorporazione delle modifiche a un progetto software il più veloce possibile. Per questo il codice viene aggiornato quotidianamente dagli sviluppatori. A tal fine, oltre ai vari strumenti di Continuous Integration vengono utilizzati soprattutto sistemi di controllo di versione come GitHub. Questi permettono di salvare sul proprio computer copie locali dell’intero progetto. I programmatori possono così apportare modifiche al codice e caricarle nel sistema di controllo della versione. L’intero programma può quindi venir sottoposto a diverse verifiche. In questo modo è possibile evitare in anticipo i problemi di integrazione.

Il modello di Continuous Delivery fa un ulteriore passo avanti rispetto all’approccio di Continuous Integration: non solo il codice viene aggiornato quotidianamente e ogni cambiamento integrato il più rapidamente possibile, ma viene anche fornito un prototipo del progetto il prima possibile al cliente. Confrontando Continuous Delivery con Continuous Integration, ci si rende conto di come Continuous Delivery si concentri principalmente sul riscontro del cliente. La consegna anticipata del codice parziale completato rende possibile testare il software del sistema nel suo ambiente reale. Tutto ciò che non piace al cliente può essere modificato nel processo di sviluppo successivo. Se, invece, al cliente piace il codice parziale, questo viene poi inserito manualmente.

Il processo di Continuous Deployment segue un approccio simile, ma ancora più esteso. Questo metodo utilizza test automatizzati che sono integrati automaticamente nel processo di sviluppo. Il confronto tra Continuous Delivery e Continuous Deployment mostra come con quest’ultimo non ci sia un ritardo tra il momento del test e il momento del rilascio del codice. Grazie all’estesa infrastruttura di verifiche, gli sviluppatori non devono nemmeno più aspettare il riscontro del cliente, ma possono distribuire il loro codice parziale direttamente dopo lo sviluppo in modo automatizzato.

Quale modello di sviluppo sia il migliore dipende interamente dai requisiti specifici del progetto. In generale, comunque, tutti e tre i modelli offrono maggiori vantaggi quando i clienti e gli sviluppatori lavorano a stretto contatto.

Il processo di Continuous Deployment è costoso a causa delle elaborate procedure di verifica, però al tempo stesso permette ai clienti di percepire quotidianamente i miglioramenti del software. Inoltre il processo di sviluppo avviene più velocemente perché non viene mai interrotto. Per questo, spesso è possibile anche risparmiare sui costi aggiuntivi per dei test a fine progetto. Con Continuous Delivery, il cliente stesso ha molto spazio di manovra, per cui i requisiti possono essere specificati anche a posteriori senza grossi svantaggi. Anche le piccole modifiche al codice sono semplici da integrare.

Il confronto tra Continuous Integration e Continuous Delivery mostra come il processo di Continuous Delivery rinunci completamente alla pubblicazione intermedia del codice. Questo metodo di lavoro si adatta quindi meglio a progetti più piccoli, dove un aggiornamento costante non solo sarebbe irrilevante, ma potrebbe anche costituire un ostacolo.