Il tempo che passa tra la decisione di apportare delle modifiche a un software e avere la modifica in produzione è una metrica di vitale importanza in ogni progetto di industria 4.0 (e non solo).

Da una parte, un lento aggiornamento di un fix può portare a un costo alto dovuto al disservizio dei clienti connessi alla piattaforma. Dall’altra parte, invece,  avere tempi di aggiornamento veloci permette di verificare che la feature rilasciata porti benefici ai clienti.  Allo stesso modo, è possibile valutare se il bugfix è stato corretto, con ottimi vantaggi in termini di ottimizzazione della performance finale della piattaforma.

Perché monitorare le tempistiche di aggiornamento?

Una piattaforma IoT è estremamente sensibile a questo tipo di problema. Per loro natura, i device IoT sono sempre connessi e la piattaforma deve offrire un servizio disponibile 24 ore su 24. Per esempio, un bug che non permette ai device di connettersi deve essere risolto il più veloce possibile per evitare di perdere dati inviati dai device.

Per questo motivo, lo Zerynth Cloud è stato progettato fin da subito con una solida pipeline di Continuous Integration/Continuos Delivery (C/I e C/D) che permette di ridurre le tempistiche di aggiornamento.

Cosa è una CI/CD?

La metodologia di uso di una CI/CD ha lo scopo di automatizzare e monitorare in modo continuo tutto il ciclo di vita di un progetto software o IoT, dalle fasi di build e test a quelle di distribuzione e deployment.

È possibile dividere la pipeline nelle due fasi di Continous Integration e Continous Delivery che, insieme, permettono di garantire che l’aggiornamento della piattaforma IoT finale sia robusta e affidabile.

Più specificatamente, la pipeline di Continuous Integration (C/I) fa sì che ad ogni modifica del codice sorgente di un servizio, un set di tests automatici vengano eseguiti per verificarne la correttezza e, se tutti i tests passano, il binario del servizio viene costruito e una nuova versione viene salvata.

La pipeline di Continuous Delivery (C/D), invece, rende possibile rilasciare in modo semiautomatico in un ambiente di staging (o production) una versione della piattaforma.

La CI/CD di Zerynth Cloud

La CI/CD per il rilascio di Zerynth Cloud è stata pensata con i seguenti requisiti:

  • Veloce. Il tempo che passa dalla modifica di un servizio fino al rilascio in produzione deve essere questione di decine minuti.
  • Automatizzata. Gli steps della pipeline devono essere automatizzati portando al minimo l’intervento manuale degli sviluppatori.
  • Riproducibile e Semplice. L’esecuzione di un aggiornamento deve essere riproducibile e semplice quanto premere un bottone (“Push-button” deploy). Non deve richiedere una conoscenza approfondita dell’architettura e tutti i membri del team devono essere in grado eseguire un rilascio.
  • Rollback di versione. Deve essere possibile ritornare a una versione precedente funzionante se l’ultima versione rilasciata non sta andando come aspettato.
  • Frequente. La pipeline deve permettere l’aggiornamento frequente di nuove funzionalità o aggiustamenti per raggiungere decine di rilasci a settimana.

Nella Figura 1 è illustrato lo schema completo della pipeline di CI/CD dello Zerynth Cloud.

aggiornamento Zerynth Cloud

Figura 1.  Schema completo della pipeline CI/CD dello Zerynth Cloud.

Zerynth Cloud: Continuous Integration

La C/I viene eseguita automaticamente quando uno sviluppatore carica una nuova versione del codice sorgente di un servizio.

Il risultato è il salvataggio di una nuova versione del servizio e il caricamento della rispettiva immagine Docker per i futuri aggiornamenti.

Il dettaglio delle operazioni eseguite nella fasi di “Commit” sono illustrate in Figura 2.

Figura 2. Operazioni della fase di “Commit” della C/I di Zerynth Cloud.

In modo automatico, viene istanziata una pipeline che esegue i seguenti passi:

  1. Checkout:  il codice sorgente del servizio viene scaricato.
  2. Unit Tests: una suite di unit tests viene eseguita. Se un test fallisce la pipeline viene abortita.
  3. Build/push Docker images: una nuova immagine docker viene costruita e salvata in un docker registry. La build viene eseguita usando buildkit che permette di ottimizzare e ridurre la costruzione delle immagini Docker.
  4. Save Build Number: una nuova versione del servizio viene salvata come un nuovo rilascio.

Il tempo di esecuzione di una singola pipeline come questa, ad esempio, può impiegare da 2 minuti fino a 5 minuti che dipende dal servizio che viene eseguito.

Un tempo davvero molto breve e sostenibile nel tempo, soprattutto se si considera come sia spesso necessario rilasciare in fretta una nuova versione per accontentare l’esigenza di un cliente nello sviluppo della sua piattaforma IoT.

Zerynth Cloud: Continuous Delivery

La pipeline di Delivery, invece, è il passo successivo alla C/I che, dopo aver salvato una nuova versione di aggiornamento, esegue o in modo automatico un rilascio nell’ambiente di test (“Test Env”) della nuova versione.

L’aggiornamento della nuova versione è caratterizzato da quattro parametri:

  • l’ambiente dove effettuare il rilascio (che può essere uno dei tre ambienti Test, Stage o Production),
  • il numero di build da rilasciare (contenuto nel repository “Release Build Numbers”),
  • le configurazioni dei servizi (contenute nel repository “App Config”),
  • le immagini Docker (scaricate dal “Container Images registry”).

Viene poi eseguita una suite di integration tests che valuta in modo automatico gli aspetti funzionali della piattaforma (per esempio, viene verificato che lo scheduling dei jobs sia funzionante oppure che i dati inviati dai device siano correttamente salvati). Questi tests sono eseguiti in background e, se falliscono, l’intero processo viene interrotto.

La fase successiva prevede che la nuova versione venga rilasciata in un ambiente di stage (“Stage Env”). Questo ambiente è del tutto analogo a quello di produzione e permette di controllare il funzionamento della  piattaforma IoT anche su aspetti non funzionali dell’architettura.

Per esempio, si possono eseguire load tests per valutare la resilienza della piattaforma in presenza di picco di carico, oppure eseguire User Acceptance Tests (UAT).

Infine, se i passi precedenti sono stati eseguiti con successo, la versione viene rilasciata in produzione. A differenza del Continuos Deployment, questa operazione viene fatta manualmente perchè prima di fare il rilascio in produzione, una nuova versione deve essere prima testata approfonditamente in stage e allinearsi con le versioni del’ SDK di Zerynth.

Nel caso che un rilascio abbia problemi, si può eseguire il rollback di una versione precedente, semplicemente indicando quale si vuole rilasciare.

Benefici finali per processi 4.0 più efficienti

Come abbiamo visto, sicuramente l’utilizzo degli schemi di pipeline scelti dalla piattaforma IoT di Zerynth permette di agevolare l’aggiornamento delle nuove versioni cloud, evitando,  in questo modo, ulteriori rallentamenti e un aumento dei costi dovuti a possibili errori.

Essere capaci di individuare velocemente il bug è fondamentale per poterlo risolvere il più velocemente possibile, con ottimi vantaggi in termini di efficienza finale della macchina, abilitata in questo modo al 4.0.

Non per ultimo, la capacità di automatizzare il processo di aggiornamento permette di avere sempre a disposizione rilasci frequenti, controllati e sicuri.Se ti interessa approfondire e capire come funziona la piattaforma Zerynth Cloud, consulta il nostro sito e richiedi una demo per avere maggiori informazioni.

Share This Story, Choose Your Platform!

About the Author: Davide Neri

Davide è l’Head of Cloud Software Development di Zerynth, è laureato in Informatica è ha conseguito il dottorato di ricerca in Informatica presso l’università di Pisa. I suoi interessi principali sono architetture Cloud a microservizi e piattaforme IOT. Nel tempo libero suona la fisarmonica e la chitarra.

Follow Zerynth on

Latest Posts