Con­ti­nuous In­te­gra­tion: cos'è l'in­te­gra­zio­ne continua

Chi lavora nel settore dello sviluppo di software conosce i problemi del­l'in­te­gra­zio­ne: quando il codice nuovo è compilato, il compito assegnato è stato svolto e rimane solo da integrare il codice sorgente nel progetto generale, ecco che emergono i problemi. Per evitare che una lunga fase di sviluppo finisca in tragedia per problemi di com­pa­ti­bi­li­tà, molti team scelgono la Con­ti­nuous In­te­gra­tion: questa prevede infatti che le modifiche vengano integrate nel progetto almeno una volta al giorno, se non di più.

La Con­ti­nuous In­te­gra­tion, proprio come la Con­ti­nuous Delivery, viene ap­prez­za­ta so­prat­tut­to nello sviluppo agile di software. L'o­biet­ti­vo di questo moderno metodo è quello di sud­di­vi­de­re il lavoro in porzioni più piccole per rendere il processo stesso di sviluppo più ef­fi­cien­te e poter reagire con maggiore fles­si­bi­li­tà alle modifiche. La Con­ti­nuous In­te­gra­tion è stata nominata per la prima volta nella de­scri­zio­ne della me­to­do­lo­gia agile Extreme Pro­gram­ming di Kent Beck. In linea di principio, tuttavia, l'idea del­l'in­te­gra­zio­ne continua esisteva già in pre­ce­den­za. Ad esempio, l'in­te­gra­zio­ne continua è im­por­tan­te anche per il metodo Booch.

L'in­te­gra­zio­ne continua offre una soluzione a scenari come questo: l'azienda sta lavorando a un progetto im­por­tan­te. Il cliente deve ricevere un software ampio e complesso. I singoli team svi­lup­pa­no solo alcuni aspetti del­l'ap­pli­ca­zio­ne mentre gli svi­lup­pa­to­ri a loro volta pro­gram­ma­no soltanto funzioni singole. Dopo mesi, se non anni, di lavoro, è arrivato il momento di unificare il tutto ed è qui che emergono i problemi. In casi come questo possono volerci al­tret­tan­ti mesi per in­di­vi­dua­re e risolvere gli errori e unificare tutte le porzioni di codice prima di poter passare alle fasi finali di testing e de­ploy­ment.

Con la Con­ti­nuous In­te­gra­tion l'in­te­gra­zio­ne di un codice nuovo avviene molto prima e non quando tutti i col­la­bo­ra­to­ri hanno già terminato il lavoro sulla propria parte. Gli svi­lup­pa­to­ri infatti caricano il proprio codice ultimato una o più volte al giorno sulla mainline, ovvero il codice sorgente a cui hanno accesso tutti i pro­gram­ma­to­ri. Dal momento che si tratta di porzioni di codice re­la­ti­va­men­te ridotte, anche l'in­te­gra­zio­ne richiede meno tempo. Uno svi­lup­pa­to­re dovrebbe impiegare qualche minuto per con­di­vi­de­re il risultato del suo lavoro con il resto del team. Nel caso in cui venga in­di­vi­dua­to un errore è possibile iden­ti­fi­car­lo e ri­sol­ver­lo in modo re­la­ti­va­men­te veloce.

In pratica la Con­ti­nuous In­te­gra­tion funziona in questo modo: uno svi­lup­pa­to­re ha il compito di svi­lup­pa­re una de­ter­mi­na­ta funzione. Prima che cominci il lavoro di pro­gram­ma­zio­ne, deve scaricare la versione attuale del codice completo del­l'ap­pli­ca­zio­ne, la co­sid­det­ta mainline. Lo svi­lup­pa­to­re potrà ora lavorare su questa versione (chiamata anche Working Copy), che ha scaricato sul suo computer personale. Una volta terminato il suo lavoro, deve testare il programma, risolvere eventuali errori e caricare la nuova versione sulla mainline.

Bisogna ricordare, tuttavia, che lo svi­lup­pa­to­re non lavora da solo sul programma. Mentre lui ha apportato le sue modifiche, molto pro­ba­bil­men­te i suoi colleghi avranno svolto altri compiti, quindi ciascun svi­lup­pa­to­re del team possiede una versione dif­fe­ren­te sul proprio computer. Anche la versione della mainline sarà si­cu­ra­men­te cambiata nel frattempo, fatto che costringe il pro­gram­ma­to­re a integrare tutte le modifiche in­nan­zi­tut­to nella sua Working Copy. Se a questo punto emerge un errore, dovrà ri­sol­ver­lo.

Solo allora il pro­gram­ma­to­re potrà ag­giun­ge­re le sue modifiche alla mainline e testare nuo­va­men­te il programma. Se non emergono altri errori, che possono pre­sen­tar­si nel caso in cui non abbia ag­gior­na­to cor­ret­ta­men­te la sua Working Copy, la procedura è conclusa e lo svi­lup­pa­to­re può dedicarsi al compito suc­ces­si­vo.

Chi vuole seguire questo metodo deve ri­spet­ta­re alcune regole: nella maggior parte dei casi i pro­gram­ma­to­ri ab­brac­cia­no i principi svi­lup­pa­ti da Martin Fowler (anch'egli svi­lup­pa­to­re di software) per una Con­ti­nuous In­te­gra­tion di successo. In­nan­zi­tut­to devono as­si­cu­rar­si che tutti i col­la­bo­ra­to­ri lavorino sullo stesso livello e che non si crei con­fu­sio­ne a causa di de­via­zio­ni dalle regole.

Sembra ovvio, ma questo è uno dei fattori più im­por­tan­ti: tutti i membri del team devono uti­liz­za­re la stessa sorgente (lo stesso re­po­si­to­ry) quando lavorano sul codice. Questo non vale soltanto per il codice sorgente di per sé, perché per garantire il corretto fun­zio­na­men­to di un'ap­pli­ca­zio­ne sono necessari anche altri elementi come le banche dati. Anche queste devono essere rag­grup­pa­te in un'unica posizione. Per questo Martin Fowler consiglia di strut­tu­ra­re un re­po­si­to­ry in modo tale che anche uno svi­lup­pa­to­re con un computer nuovo possa col­la­bo­ra­re e che tutti i file necessari siano de­po­si­ta­ti in una posizione centrale.

Per creare un programma fun­zio­nan­te dal codice sorgente è ne­ces­sa­rio com­pi­lar­lo, at­tua­liz­za­re le banche dati e spostare i file nelle posizioni corrette. Questo processo può essere au­to­ma­tiz­za­to. Ideal­men­te dovrebbe essere possibile eseguire un processo di build con un solo comando.

L'in­te­gra­zio­ne di mec­ca­ni­smi di testing nel processo di build consente al team di au­to­ma­tiz­za­re, e dunque ve­lo­ciz­za­re ul­te­rior­men­te, la Con­ti­nuous In­te­gra­tion. Proprio come il processo di build, anche i test devono poter essere eseguiti nel modo più ef­fi­cien­te possibile (la cosa migliore è im­ple­men­ta­re una serie di mec­ca­ni­smi di controllo diversi).

L'in­te­gra­zio­ne continua può fun­zio­na­re solo se tutti i membri del team con­di­vi­do­no il sistema. È suf­fi­cien­te che un membro del team non integri co­stan­te­men­te il suo codice nella mainline perché tutti gli altri partano da pre­sup­po­sti sbagliati. Tutti presumono di lavorare su un sistema stabile, ma se uno di loro non dovesse con­di­vi­de­re il suo codice per un periodo pro­lun­ga­to (più di un giorno), la ricerca di errori può diventare una vera sfida. Come accade spesso nella vita, anche nella Con­ti­nuous In­te­gra­tion la co­mu­ni­ca­zio­ne gioca un ruolo fon­da­men­ta­le, infatti se tutti gli svi­lup­pa­to­ri restano ag­gior­na­ti sul lavoro degli altri, molte dif­fi­col­tà possono essere prevenute.

Il codice di pro­gram­ma­zio­ne contenuto nella mainline deve essere sempre testato e fun­zio­nan­te. Per questo ogni svi­lup­pa­to­re deve integrare il suo codice uni­ca­men­te in questo ramo prin­ci­pa­le e non in uno se­con­da­rio. In tal senso ogni svi­lup­pa­to­re deve inoltre ve­ri­fi­ca­re che il suo codice sia fun­zio­nan­te quindi, dopo l'in­te­gra­zio­ne, dovrà testare nuo­va­men­te il codice insieme al build. Se vengono ri­scon­tra­ti degli errori dovrà ri­sol­ver­li. In questo modo viene garantito che il codice è privo di difetti.

Nella Con­ti­nuous In­te­gra­tion è di fon­da­men­ta­le im­por­tan­za che la mainline non contenga mai una versione difettosa. Questo significa per gli svi­lup­pa­to­ri che la ri­pa­ra­zio­ne non deve mai essere rimandata. Secondo Martin Fowler il fatto che i build non fun­zio­ni­no e che sia ne­ces­sa­rio rivedere il codice non è un problema, ma il sistema del­l'in­te­gra­zio­ne continua prevede una ri­pa­ra­zio­ne immediata. Tutti gli svi­lup­pa­to­ri devono infatti poter contare sul fatto che il codice nella mainline sia fun­zio­nan­te, al­tri­men­ti l'intero team effettua pro­gram­ma­zio­ni in sistemi instabili in­ne­scan­do una valanga di errori.

La vera e propria in­te­gra­zio­ne del codice (incluso il testing) deve avvenire piuttosto ve­lo­ce­men­te. L'Extreme Pro­gram­ming (XP) prevede appena 10 minuti per questo compito. Con­si­de­ran­do che uno svi­lup­pa­to­re effettua in genere più di un'in­te­gra­zio­ne al giorno, tempi di build più lunghi pro­vo­che­reb­be­ro delle perdite di tempo con­si­sten­ti. Per questo motivo è es­sen­zia­le adottare mec­ca­ni­smi che per­met­ta­no di ve­lo­ciz­za­re il processo.

Per poter rag­giun­ge­re tempi così ridotti bisogna anche accettare il fatto che non tutti i test potranno essere eseguiti di­ret­ta­men­te. Per questo viene adottato un sistema a due fasi: nella prima fase, che si svolge durante il lavoro quo­ti­dia­no, si eseguono test in modo da ridurre i tempi di build. La seconda fase di test, invece, dura diverse ore e prevede anche verifiche più ap­pro­fon­di­te.

Si consiglia ge­ne­ral­men­te di eseguire i test in un ambiente esterno e sicuro, che deve comunque essere con­fi­gu­ra­to esat­ta­men­te come l'am­bien­te di pro­du­zio­ne. Questo può talvolta diventare ab­ba­stan­za di­spen­dio­so, dal momento che la macchina deve essere con­fi­gu­ra­ta in maniera identica. La vir­tua­liz­za­zio­ne di interi computer consente tuttavia di ridurre sempre di più questi costi.

Tutti i col­la­bo­ra­to­ri devono poter accedere fa­cil­men­te al­l'ul­ti­ma versione ed essere in grado di eseguire il programma. Garantire questa con­di­zio­ne non presenta dif­fi­col­tà par­ti­co­la­ri: con­si­de­ran­do che la Con­ti­nuous In­te­gra­tion prevede in ogni caso che tutti i file vengano de­po­si­ta­ti in un re­po­si­to­ry, è suf­fi­cien­te as­si­cu­ra­re che tutti conoscano questa posizione. I motivi a favore sono diversi: i tester possono iniziare test ag­giun­ti­vi mentre il processo di pro­gram­ma­zio­ne è ancora in corso, gli sta­ke­hol­der possono uti­liz­za­re i file ese­gui­bi­li per di­mo­stra­zio­ni e i manager della qualità possono con­trol­la­re le cifre.

Sapere chi ha in­tro­dot­to quali modifiche è tanto im­por­tan­te quanto garantire l'accesso di tutti i col­la­bo­ra­to­ri al codice sorgente e al file ese­gui­bi­le. Come parte in­te­gran­te della co­mu­ni­ca­zio­ne, è fon­da­men­ta­le che gli svi­lup­pa­to­ri si informino a vicenda su chi sta lavorando su quale processo di build. A tale scopo alcuni team sfruttano display separati o raf­fi­gu­ra­zio­ni visive che evi­den­zi­no che si è at­tual­men­te impegnati con un’in­te­gra­zio­ne.

Infine è fon­da­men­ta­le au­to­ma­tiz­za­re la sud­di­vi­sio­ne del software. I file devono essere tra­sfe­ri­ti da un ambiente all'altro, passaggio che può ri­chie­de­re molto tempo. Per questo è con­si­glia­to l'u­ti­liz­zo degli script che au­to­ma­tiz­za­no e ve­lo­ciz­za­no questo processo.

No­no­stan­te le sue ca­rat­te­ri­sti­che positive, nel lavoro quo­ti­dia­no la Con­ti­nuous In­te­gra­tion non offre solo dei vantaggi. Infatti, è vero che consente di evitare un'ampia e pro­lun­ga­ta fase di in­te­gra­zio­ne alla fine del processo e permette di risolvere i problemi tem­pe­sti­va­men­te, ma per un team ben coor­di­na­to l'a­dat­ta­men­to alla Con­ti­nuous In­te­gra­tion può risultare difficile. In questi casi il metodo può persino provocare l'effetto contrario e risultare più di­spen­dio­so in termini di tempo.

In linea di principio è possibile gestire l'in­te­gra­zio­ne continua anche senza strumenti specifici, dato che tutte le fasi di lavoro possono essere eseguite anche ma­nual­men­te. Questo approccio ri­chie­de­reb­be comunque molta di­sci­pli­na e un impegno ancora maggiore. L'u­ti­liz­zo di strumenti appositi può dunque sem­pli­fi­ca­re no­te­vol­men­te il lavoro. Questi strumenti in genere mettono a di­spo­si­zio­ne un server e aiutano nel building e nel controllo delle versioni.

• Jenkins: si tratta di un programma molto popolare scritto in lin­guag­gio Java, nato come al­ter­na­ti­va di Hudson, il cui sviluppo è stato in­ter­rot­to. Questo software open source lavora con diversi strumenti di building e sistemi di gestione delle versioni.
• Travis CI: questo strumento per l'in­te­gra­zio­ne continua è così ap­prez­za­to perché è per­fet­ta­men­te com­pa­ti­bi­le con GitHub. Il re­po­si­to­ry online informa Travis sulle modifiche del codice. Il software è di­spo­ni­bi­le gra­tui­ta­men­te per progetti open source o in una versione a pagamento per tutti gli altri utilizzi.
• Bamboo: il server Bamboo consente agli svi­lup­pa­to­ri di svolgere l'in­te­gra­zio­ne, il de­ploy­ment e la gestione delle release. Il pro­dut­to­re Atlassian offre il software sotto forma di piat­ta­for­ma web basata su Java. Bamboo è molto ap­prez­za­to dagli svi­lup­pa­to­ri per l'au­to­ma­tiz­za­zio­ne ed è com­pa­ti­bi­le con diversi strumenti di building. Il software, so­li­ta­men­te a pagamento, è di­spo­ni­bi­le anche gra­tui­ta­men­te per i progetti open source.
• Gitlab CI: GitLab offre un proprio programma per l'in­te­gra­zio­ne continua, com­pa­ti­bi­le con la gestione nota delle versioni. La pipeline può essere per­so­na­liz­za­ta e adattata a ogni singolo progetto. GitLab supporta inoltre CI Docker.
• CircleCI: di questo programma per la Con­ti­nuous In­te­gra­tion esistono due versioni dif­fe­ren­ti. È possibile scegliere una versione di­ret­ta­men­te nel Cloud del­l'o­pe­ra­to­re o creare un proprio server locale per il suo utilizzo.
• Crui­se­Con­trol: svi­lup­pa­to ori­gi­na­ria­men­te da Thought­Works (un'a­zien­da in­cen­tra­ta su Martin Fowler), oggi Crui­se­Con­trol è diventato un progetto in­di­pen­den­te. Il software gratuito è basato su Java ed è dunque in­di­pen­den­te dalle piat­ta­for­me. Tra l'altro Crui­se­Con­trol offre agli svi­lup­pa­to­ri una dashboard (un proprio sito Internet) sul quale è possibile ve­ri­fi­ca­re lo stato dei build.
• Codeship: l'o­biet­ti­vo di Codeship è offrire agli svi­lup­pa­to­ri una soluzione semplice per la Con­ti­nuous In­te­gra­tion. Grazie alla tec­no­lo­gia basata su container, è molto semplice creare au­to­ma­ti­smi. L'azienda offre a tale scopo due versioni: Basic e Pro.
• TeamCity: il software com­mer­cia­le TeamCity punta par­ti­co­lar­men­te sul­l'in­te­ro­pe­ra­bi­li­tà con altri strumenti. Già nella versione standard vengono sup­por­ta­ti molti programmi, ma questa gamma può essere ul­te­rior­men­te ampliata mediante i plug-in. Una par­ti­co­la­ri­tà sta sen­z'al­tro nel Pre-Tested Commit. TeamCity verifica au­to­no­ma­men­te il codice appena compilato ancora prima del­l'in­te­gra­zio­ne nella mainline e segnala eventuali errori allo svi­lup­pa­to­re.