<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">

Red Blog

Continuous testing: come automatizzare la testing pipeline grazie ai container

Luigi De Masi,

Continuous testing: come automatizzare la testing pipeline grazie ai container

Il mercato di oggi si sta evolvendo a un ritmo ancora più veloce di prima. I team sono sotto pressione per evolversi e adattarsi. Più velocità, più qualità, più funzionalità. Di più, più veloce, ma senza bug.
In realtà, a volte questi fattori possono essere in contrasto tra loro. In molti casi, i team si occupano ancora di lunghi cicli di test, creando e manutenendo ambienti di test e tenendo il passo con l'automazione complessa: vediamo come rendere tutto più semplice con l'implementazione del continuous testing!

Scopri come velocizzare il Time-To-Market delle applicazioni con OpenShift!

 

Oggi, i container hanno rivoluzionato il modo di usare le applicazioni tramite servizi preconfigurati quali bilanciamento del carico e scalabilità. Non offrono solo un'infrastruttura per eseguire il codice ma in realtà offrono molto di più: hanno cambiato l'approccio al CI/CD. Viene ancora utilizzato Jenkins per gestire il workflow, ma in modo dinamico, per risparmiare risorse quando non sono in uso. Viene mantenuto il flusso tradizionale: si parte dal codice sorgente, che viene compilato, vengono eseguiti i test di unità e creata l'immagine del container. Poi si passa al deployment in ambiente OpenShift che grazie al provisioning dinamico dei container consente di risparmiare tempo e risorse, permettendo comunque l'implementazione di attività di continuous testing nella pipeline. A questo semplice flusso, infatti, si aggiungono i test d'integrazione.

L'introduzione del continuous testing: cosa cambia rispetto al passato

In passato, i test d'integrazione avvenivano in ambienti ad hoc e nel caso di un'applicazione con dipendenze e servizi attivi, la sola manutenzione dell'ambiente poteva essere difficile. Un' applicazione richiede un database, un message broker, nel caso di messaging asincrono o una cache di memoria distribuita. Nel caso dei microservizi, l'app necessita anche di altri servizi per poter funzionare.
Con strumenti come OpenShift è possibile creare un intero ambiente per il test d'integrazione on-demand. I container offrono immagini praticamente per ogni tipo di applicazione.
È possibile utilizzare Docker hub, Clay.io, o le versioni supportate di Red Hat e nell'arco di un minuto, potete avere un ambiente di integrazione completo.
Un vantaggio importante è che il deployment dell'applicazione sfrutta la stessa immagine usata in produzione, questo significa meno tempo dedicato alla configurazione degli ambienti, al debug di problemi specifici dell'ambiente e ad una base di codice più portatile e facile da configurare.

Dopo l'attivazione dei container delle dipendenze, si può passare al test tramite chiamata all'API o code di messaggi o in qualunque modo l’applicazione esponga le sue funzionalità.
È inoltre possibile interagire in modo dinamico con l'ambiente durante i test d'integrazione: possiamo attivare e disattivare container per simulare il downtime del database, simulare uno scenario specifico o riprodurre un bug segnalato in produzione e, al termine del test, l'ambiente viene ripulito automaticamente permettendo rendendo così possibile il continuous testing.

La volta successiva, si riparte da zero, non serve fare pulizia dopo i test, i servizi non avranno bisogno di patch purché l'ultima immagine provenga da un registro affidabile e sicuro.
Questo processo ci obbliga ad automatizzare, a creare script fin dal primo istante: gli interventi temporanei effettuati manualmente non funzionano, in quanto al prossimo run verrebbero azzerati. Tutte le modifiche quindi, devono essere parte del processo, evitando così che si perda traccia delle modifiche apportate all’ambiente.

Continuous testing sì, ma attenzione agli aspetti organizzativi

Il continuous testing aiuta molto nello sviluppo del progetto ed è fondamentale se si vuole aumentare il rate di rilascio in produzione, ma può anche essere molto impegnativo. Bisogna valutare bene i rischi e avere un piano solido, condiviso con ciascun team, su come è possibile integrarlo nelle proprie procedure per mantenere il flusso dei test attivo durante il processo di sviluppo. Ciò comporta l'eliminazione dei silos tra ciascun team: gli sviluppatori, i tester e gli Ops dovranno ora lavorare insieme. Per approfondire l'argomento e scoprire tutte le potenzialità di OpenShift scarica il nostro e-book gratuito "Velocizzare il Time-to-market delle applicazioni con OpenShift"! 

Velocizzare Time-To-Market applicazioni con OpenShift

Share this post

  

Commenti

Prova Red Cloud Gratis per 30 Giorni

Iscriviti alla newsletter

Condividi questo blog

   

Post correlati