Con­ti­nuous In­te­gra­tion, Con­ti­nuous Delivery e Con­ti­nuous De­ploy­ment: tre modelli di sviluppo del software a confronto

I processi di sviluppo del software sono costosi. Spe­cial­men­te quando il nuovo codice non può essere integrato con facilità nel software esistente, i costi salgono alle stelle. I moderni approcci di Con­ti­nuous In­te­gra­tion, Delivery e De­ploy­ment (tra­du­ci­bi­li in italiano come “in­te­gra­zio­ne continua”, “consegna continua” e “di­stri­bu­zio­ne continua”) for­ni­sco­no un rimedio al problema. Questi modelli fanno af­fi­da­men­to sulla convalida multipla del codice già durante il suo sviluppo. Lavorare in diverse fasi di sviluppo più piccole permette anche di con­se­gna­re al cliente dei prototipi del prodotto de­si­de­ra­to. In questo modo, il cliente può ag­gior­na­re le sue richieste in fase di sviluppo e ve­ri­fi­ca­re di volta in volta se il software assume la forma de­si­de­ra­ta.

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 ac­ce­le­ra­re lo sviluppo del software, ma anche a renderlo più tra­spa­ren­te. L’obiettivo dell’approccio agile è quello di svi­lup­pa­re software di cui il cliente ha veramente bisogno. At­tra­ver­so i prototipi che vengono messi a di­spo­si­zio­ne durante tutta la fase di sviluppo, il cliente può ve­ri­fi­ca­re se il software fa ef­fet­ti­va­men­te quello che dovrebbe fare e se è com­pa­ti­bi­le con il software pre­e­si­sten­te. 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 ve­lo­ciz­za­re i processi di sviluppo all’interno delle aziende. Uno di questi è DevOps. Il termine DevOps nasce dalla com­bi­na­zio­ne dei termini inglesi “De­ve­lo­p­ment” (sviluppo) e “Ope­ra­tions” (or­ga­niz­za­zio­ne). Lo scopo di questa cultura aziendale è quello di far sì che i team di sviluppo lavorino assieme ai team or­ga­niz­za­ti­vi durante tutta la fase di sviluppo di un software e oltre. Ciò permette di evitare problemi di in­te­gra­zio­ne del software fin dall’inizio e facilita il controllo e la di­stri­bu­zio­ne dei programmi finiti. Oltre allo sviluppo continuo, i rap­pre­sen­tan­ti di DevOps fanno af­fi­da­men­to anche su Con­ti­nuous In­te­gra­tion e Con­ti­nuous De­ploy­ment.

Il modello di Con­ti­nuous In­te­gra­tion ha come scopo quello di rendere l’in­cor­po­ra­zio­ne delle modifiche a un progetto software il più veloce possibile. Per questo il codice viene ag­gior­na­to quo­ti­dia­na­men­te dagli svi­lup­pa­to­ri. A tal fine, oltre ai vari strumenti di Con­ti­nuous In­te­gra­tion vengono uti­liz­za­ti so­prat­tut­to sistemi di controllo di versione come GitHub. Questi per­met­to­no di salvare sul proprio computer copie locali dell’intero progetto. I pro­gram­ma­to­ri possono così apportare modifiche al codice e caricarle nel sistema di controllo della versione. L’intero programma può quindi venir sot­to­po­sto a diverse verifiche. In questo modo è possibile evitare in anticipo i problemi di in­te­gra­zio­ne.

Il modello di Con­ti­nuous Delivery fa un ulteriore passo avanti rispetto all’approccio di Con­ti­nuous In­te­gra­tion: non solo il codice viene ag­gior­na­to quo­ti­dia­na­men­te e ogni cam­bia­men­to integrato il più ra­pi­da­men­te possibile, ma viene anche fornito un prototipo del progetto il prima possibile al cliente. Con­fron­tan­do Con­ti­nuous Delivery con Con­ti­nuous In­te­gra­tion, ci si rende conto di come Con­ti­nuous Delivery si concentri prin­ci­pal­men­te sul riscontro del cliente. La consegna an­ti­ci­pa­ta del codice parziale com­ple­ta­to rende possibile testare il software del sistema nel suo ambiente reale. Tutto ciò che non piace al cliente può essere mo­di­fi­ca­to nel processo di sviluppo suc­ces­si­vo. Se, invece, al cliente piace il codice parziale, questo viene poi inserito ma­nual­men­te.

Il processo di Con­ti­nuous De­ploy­ment segue un approccio simile, ma ancora più esteso. Questo metodo utilizza test au­to­ma­tiz­za­ti che sono integrati au­to­ma­ti­ca­men­te nel processo di sviluppo. Il confronto tra Con­ti­nuous Delivery e Con­ti­nuous De­ploy­ment 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 in­fra­strut­tu­ra di verifiche, gli svi­lup­pa­to­ri non devono nemmeno più aspettare il riscontro del cliente, ma possono di­stri­bui­re il loro codice parziale di­ret­ta­men­te dopo lo sviluppo in modo au­to­ma­tiz­za­to.

Quale modello di sviluppo sia il migliore dipende in­te­ra­men­te dai requisiti specifici del progetto. In generale, comunque, tutti e tre i modelli offrono maggiori vantaggi quando i clienti e gli svi­lup­pa­to­ri lavorano a stretto contatto.

Il processo di Con­ti­nuous De­ploy­ment è costoso a causa delle elaborate procedure di verifica, però al tempo stesso permette ai clienti di percepire quo­ti­dia­na­men­te i mi­glio­ra­men­ti del software. Inoltre il processo di sviluppo avviene più ve­lo­ce­men­te perché non viene mai in­ter­rot­to. Per questo, spesso è possibile anche ri­spar­mia­re sui costi ag­giun­ti­vi per dei test a fine progetto. Con Con­ti­nuous Delivery, il cliente stesso ha molto spazio di manovra, per cui i requisiti possono essere spe­ci­fi­ca­ti anche a po­ste­rio­ri senza grossi svantaggi. Anche le piccole modifiche al codice sono semplici da integrare.

Il confronto tra Con­ti­nuous In­te­gra­tion e Con­ti­nuous Delivery mostra come il processo di Con­ti­nuous Delivery rinunci com­ple­ta­men­te alla pub­bli­ca­zio­ne in­ter­me­dia del codice. Questo metodo di lavoro si adatta quindi meglio a progetti più piccoli, dove un ag­gior­na­men­to costante non solo sarebbe ir­ri­le­van­te, ma potrebbe anche co­sti­tui­re un ostacolo.