Per quanto possa sembrare banale, anche la modifica della più piccola funzionalità all’interno di un sito o di un’app richiede spesso mesi di sviluppo, test e verifiche prima di essere rilasciata ai clienti. 

Vi siete mai chiesti come funzionano l’integrazione e la pubblicazione di questi aggiornamenti?

Il metodo più “tradizionale” si basa sul concetto di branch, ovvero rami diversi di uno stesso progetto, creati per lavorare all’aggiunta o alla modifica di funzionalità senza intaccare il codice di base del progetto. Ogni sviluppatore lavora quindi in un branch indipendente e, al termine del ciclo di sviluppo, tutti i rami vengono uniti (e testati) per funzionare assieme.

Quando però vi è la necessità di accelerare il rilascio di un software, i tempi di collaudo che seguono l’integrazione dei diversi branch si riducono, generando spesso malfunzionamenti e bug. Ciò che ne consegue sono ulteriori test e rimaneggiamenti del codice: una situazione spesso definita integration hell (o inferno dell’integrazione).

Qui entra in gioco il CI/CD (Continuous Integration, Continuous Deployment), un metodo per la distribuzione frequente delle app ai clienti che prevede un alto livello di automatizzazione. Questo approccio supera le difficoltà legate alla modifica o all’aggiunta di funzionalità in applicazioni già rilasciate, grazie all’automatizzazione e al monitoraggio continuo del codice in tutto il ciclo di vita delle applicazioni, dalle fasi di integrazione e test a quelle di distribuzione e deployment.

Vediamolo più nel dettaglio.

Continuous Integration

“Integrazione continua” si riferisce alla costante unione delle modifiche apportate al codice, che vengono testate in un repository condiviso, permettendo di individuare e risolvere preventivamente i conflitti generati delle numerose diramazioni di un’applicazione in fase di sviluppo.

Continuous Deployment

“Distribuzione continua” e/o “deployment continuo” sono concetti correlati. Se usati distintamente indicano il livello di automazione applicato, ma sono più spesso impiegati in modo intercambiabile per riferirsi all’automazione delle fasi finali del ciclo di sviluppo. 

Le modifiche apportate da uno sviluppatore all’applicazione vengono quindi automaticamente testate alla ricerca di bug e caricate in un repository (come GitHub, GitLab o un registro per container). Il fine è quello di garantire interventi manuali minimi per distribuire il nuovo codice ai clienti. In tal modo si evita di sovraccaricare i team operativi con procedure manuali.

Il flusso CI/CD

In sintesi, con CI/CD si intende quindi un flusso altamente automatizzato di integrazione e monitoraggio continuo allo sviluppo delle applicazioni. L’esatto significato del termine dipenderà, di volta in volta, dalla quantità di automazione integrata. Molte aziende, ad esempio, iniziano dalla Continuous Integration per poi aggiungere il Continuous Deployment, ad esempio come parte di applicazioni cloud native.

CI/CD in Zelando

In Zelando abbiamo infatti iniziato a utilizzare la Continuous Integration nei nostri prodotti, che offre già diversi vantaggi:

• garantisce un ambiente di test in cui collaudare i risultati dell’unione dei vari branch
• assicura una versione stabile del progetto prima della pubblicazione, evitando le problematiche legate alla versione in sviluppo
• permette di risparmiare il tempo solitamente dedicato alla compilazione del codice (build) e alla pubblicazione del progetto sul server

L’integrazione continua è solo una delle metodologie di sviluppo utilizzate dal nostro Team, continua a seguire il nostro blog per approfondimenti come questo