Automazione e feedback: chiusura del ciclo DevOps
Tempo di lettura: 4 min

In Capitolo 5: Branching e Continuous Deployment, abbiamo analizzato come i rami di breve durata e una piattaforma centralizzata di continuous deployment (CD) ci abbiano aiutato ad accelerare i rilasci e a ridurre i problemi di integrazione. Questi cambiamenti hanno migliorato notevolmente il flusso di codice verso la produzione, ma per completare davvero il ciclo di feedback DevOps avevamo bisogno di qualcosa in più.

Capitolo 6, la sezione conclusiva della nostra serie DevOps for the Win, approfondisce l'ultimo ma fondamentale pilastro della nostra trasformazione: automazione e feedback. Se il continuous deployment ci ha aiutato a rilasciare più velocemente, l'automazione e il feedback ci hanno permesso di apprendere più rapidamente, consentendoci di migliorare continuamente in sicurezza.

Perché l'automazione e il feedback sono importanti

In qualsiasi processo di trasformazione DevOps, la velocità senza sicurezza è la ricetta ideale per il disastro. Con l'aumentare della frequenza dei rilasci, la necessità di controlli automatizzati e feedback in tempo reale è diventata fondamentale, non solo per il controllo qualità, ma anche per responsabilizzare il team e facilitare i processi decisionali.

I sistemi di automazione e feedback offrono ai team:

  • Individuazione tempestiva dei problemi prima che raggiungano la produzione
  • Fiducia nelle modifiche, grazie a una convalida ripetibile e affidabile
  • Metriche approfondite per comprendere lo stato del sistema e l'impatto sugli utenti

È la differenza tra viaggiare alla cieca e farlo con un cruscotto di controllo.

Dopo aver migliorato la velocità di sviluppo, ci siamo concentrati sull'individuazione dei colli di bottiglia nel ciclo di feedback, una volta che il team di sviluppo contrassegnava il lavoro come "completato". In questo caso, la principale misura del flusso era la rapidità con cui il lavoro completato poteva essere rilasciato in produzione.

Il tempo di lead time per le modifiche e la frequenza dei rilasci sono parametri fondamentali per misurare l'efficienza con cui il lavoro scorre nel sistema. Nel nostro caso, il lavoro si accumulava nella fase di QA del sistema (SQA), creando un collo di bottiglia nella prontezza al rilascio.

Il collo di bottiglia della QA di sistema

Nella maggior parte degli ambiti, compreso il nostro, i requisiti normativi impongono una serie di attività di convalida per garantire la qualità del software. Queste includono:

  • Test di integrazione
  • Test a livello di sistema
  • Test non funzionali (ad esempio, verifica della rete, test delle prestazioni)
  • Artifact di convalida → Report di test di sistema, IQ (Qualificazione dell'Installazione), OQ (Qualificazione Operativa) e PQ (Qualificazione delle Prestazioni)

Queste attività devono essere eseguite in ambienti controllati, separati dallo sviluppo, per garantire la conformità. Per questo motivo, il team di QA del sistema opera in modo indipendente e i test possono iniziare solo dopo che il team di sviluppo ha completato il proprio lavoro.

I nostri cruscotti indicavano che il tempo necessario per portare il lavoro completato allo stato pronto per la produzione era in aumento, con una quantità crescente di lavoro in attesa che l'SQA iniziasse i test. Seguendo il nostro approccio fondamentale per migliorare il flusso, questo era un problema che dovevamo risolvere prima che qualsiasi ulteriore ottimizzazione DevOps potesse mostrare un reale valore.

Principali sfide nel flusso dallo sviluppo alla SQA

Vi erano due sfide principali nel migliorare il flusso di lavoro dallo sviluppo alla QA di sistema:

  1. Il ritardo nell'avvio delle attività di SQA
  2. La velocità con cui è possibile eseguire la convalida del sistema

Se i test di SQA sono prevalentemente manuali, possono iniziare solo una volta che il codice è interamente sviluppato e distribuito in ambienti controllati. Questo determina sia il momento in cui i test possono iniziare sia il tempo necessario per completarli. Il massimo che la SQA può fare in questo modello è preparare in anticipo gli script di test, attendendo il raggiungimento della Definizione di Fatto (DoD) del team di sviluppo prima di eseguirli.

Automazione della SQA: un cambiamento nella strategia di test

L'unico modo per migliorare questo flusso è puntare in modo massiccio sull'automazione. Tuttavia, non si tratta solo di automatizzare l'esecuzione dei test, ma richiede un cambiamento fondamentale nell'approccio ai test stessi. Questo include:

  • Ridefinire e riallineare gli obiettivi della QA di sistema.
  • Rivalutare le modalità di esecuzione della convalida per soddisfare sia i requisiti di velocità sia quelli normativi.
  • Ripensare gli strumenti e i framework necessari per supportare efficacemente l'automazione.

Uno dei cambiamenti chiave nella mentalità è stato il passaggio dal testare per confermare che il software sviluppato funzioni al testare per guidare lo sviluppo.

Ciò significava creare, automatizzare ed eseguire script di test in un ambiente in cui il codice di sviluppo viene regolarmente inviato, ancor prima di raggiungere la DoD della funzionalità. In questo caso, il fallimento dei test non indica un difetto, bensì fornisce un'indicazione precoce su quali parti della funzionalità non siano ancora implementate o pienamente operative.

Con pipeline di consegna continua e una strategia di branching perfezionata, in cui i branch delle funzionalità vengono uniti frequentemente nel branch principale e distribuiti nel cloud, abbiamo configurato un ambiente dedicato in cui questi test di sistema automatizzati potevano essere eseguiti continuamente.

Feedback più rapido grazie ai test automatizzati

Questo approccio ha permesso alla QA del sistema di avviare la validazione in anticipo, rendendo i test più rapidi e fornendo un riscontro più tempestivo al team di sviluppo. Invece di attendere che una funzionalità venga contrassegnata come completata, i test vengono eseguiti in parallelo con lo sviluppo, offrendo ai team informazioni in tempo reale su ciò che funziona e su ciò che deve ancora essere completato.

Allo stesso tempo, l'automazione dei casi di test ha richiesto un ripensamento delle strategie di testing.

  • Il superamento dell'automazione basata su UI ha reso il testing delle API la priorità.
  • Passaggio allo Sviluppo Guidato dal Comportamento (BDD) → Creazione di script di test insieme alle storie degli utenti da includere nei criteri di accettazione.

Sebbene l'adozione completa del BDD sin dall'inizio della creazione delle storie degli utenti sia ancora in corso, abbiamo migliorato la collaborazione tra i team di SQA e di sviluppo, allineandoli tempestivamente nel processo.

Allineamento di SQA e sviluppo: l'influenza dei Team Topologies

Per ottenere questo risultato, abbiamo applicato l'approccio del team specializzato tratto da Team Topologies, configurando il team SQA come team abilitante. Invece di essere una funzione di test separata e a valle, i membri del team SQA sono stati strettamente allineati allo sviluppo per garantire che la creazione dei casi di test di automazione inizi presto e prosegua continuamente man mano che il codice viene sviluppato.

Un prerequisito fondamentale per questo approccio è la disponibilità di un ambiente di test Cloud-based per eseguire test a livello di sistema prima di passare ad ambienti controllati. Sebbene ciò comporti costi infrastrutturali aggiuntivi, aumenta in modo significativo il flusso di lavoro dallo sviluppo alla SQA, rendendo il codice pronto per il rilascio molto più rapidamente.

Conclusione

Questo miglioramento rafforza un principio fondamentale di DevOps: affrontare la trasformazione considerando le competenze relative a Strumenti, Architettura e Persone, concentrandosi al contempo sul flusso. Automatizzando la QA del sistema, integrando i test prima nel ciclo e allineando i team in modo più efficace, abbiamo ridotto significativamente il collo di bottiglia tra lo sviluppo e la validazione del sistema, accelerando i cicli di feedback e rendendo i rilasci più fluidi.

Conclusione della serie

Mentre concludiamo la nostra serie DevOps for the Win, riflettiamo sul percorso che ci ha portato dal caos degli strumenti e dei processi manuali a un'organizzazione più connessa, automatizzata e autonoma. Dalla definizione del nostro triangolo DevOps nel Capitolo 1 alla creazione di un apprendimento basato sul feedback nel Capitolo 6, ciascun capitolo si è basato sul precedente per guidare una trasformazione significativa.

Ecco un breve riepilogo della nostra serie:

Questa trasformazione è continua, ma grazie alle fondamenta che abbiamo costruito siamo più equipaggiati che mai per offrire valore in modo più rapido, sicuro e intelligente.

Grazie per averci seguito in questo percorso. Ci auguriamo che la nostra storia sia di ispirazione per la vostra evoluzione DevOps.

Mantenete la curiosità. Procedete per iterazioni. E, cosa più importante, restate connessi.

Iscriviti al blog di Freyr