Automazione e feedback: chiudere il ciclo DevOps
4 minuti di lettura

Nel Capitolo 5: Branching e Continuous Deployment, abbiamo esplorato come i rami a breve termine e una piattaforma centralizzata di continuous deployment (CD) ci abbiano aiutato ad accelerare la consegna e a ridurre l'attrito nell'integrazione. Questi cambiamenti hanno migliorato drasticamente il flusso di codice verso la produzione, ma per completare veramente il ciclo di feedback DevOps, avevamo bisogno di altro.

Capitolo 6, il segmento finale della nostra serie DevOps for the Win, si immerge nell'ultimo ma vitale pilastro della nostra trasformazione: Automazione e Feedback. Se la distribuzione continua ci ha aiutato a rilasciare più velocemente, l'automazione e il feedback ci hanno aiutato a imparare più velocemente, consentendoci di migliorare continuamente con fiducia.

Perché l'automazione e il feedback sono importanti

In qualsiasi trasformazione DevOps, la velocità senza sicurezza è una ricetta per il disastro. Con l'aumento della nostra frequenza di implementazione, la necessità di controlli automatizzati e feedback in tempo reale è diventata fondamentale, non solo per la garanzia della qualità, ma anche per l'autonomia del team e il processo decisionale.

I sistemi di automazione e feedback offrono ai team:

  • Rilevamento precoce dei problemi prima che raggiungano la produzione
  • Fiducia nei cambiamenti, attraverso una validazione ripetibile e affidabile
  • Metriche approfondite per comprendere lo stato del sistema e l'impatto sugli utenti

È la differenza tra volare alla cieca e volare con un quadro di controllo.

Dopo aver migliorato la velocità di sviluppo, il nostro prossimo obiettivo è stato identificare i colli di bottiglia nel ciclo di feedback una volta che il team di sviluppo ha contrassegnato il lavoro come 'fatto'. Qui, la misura principale del flusso era la velocità con cui il lavoro completato poteva essere implementato in produzione.

Il tempo di consegna per il cambiamento e la frequenza di implementazione sono metriche chiave per misurare l'efficienza con cui il lavoro si muove attraverso il sistema. Nel nostro caso, il lavoro si accumulava nella fase di QA del sistema (SQA), creando un collo di bottiglia nella preparazione all'implementazione.

Il Collo di Bottiglia del QA del Sistema

Nella maggior parte dei settori, incluso il nostro, i requisiti normativi impongono una serie di attività di convalida per garantire la qualità del software. Ciò include:

  • Test di integrazione
  • Test a Livello di Sistema
  • Test non funzionali (ad esempio, verifica della rete, test delle prestazioni)
  • Artefatti di Validazione → Rapporti di Test del Sistema, IQ (Qualificazione dell'Installazione), OQ (Qualificazione Operativa) e PQ (Qualificazione delle Prestazioni)

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

Le nostre dashboard hanno mostrato che il tempo necessario per spostare il lavoro completato allo stato di pronto per la produzione stava aumentando, con più lavoro in attesa che la SQA iniziasse i test. Seguendo il nostro approccio fondamentale per migliorare il flusso, questo era un problema che dovevamo affrontare prima che qualsiasi ulteriore ottimizzazione DevOps potesse mostrare un valore reale.

Sfide principali nel flusso dallo sviluppo alla SQA

C'erano due sfide principali nel migliorare il flusso di lavoro dallo sviluppo al QA del sistema:

  1. Il ritardo nell'avvio delle attività SQA
  2. La velocità con cui la validazione del sistema poteva essere eseguita

Se i test SQA sono principalmente manuali, possono iniziare solo una volta che il codice è completamente sviluppato e distribuito in ambienti controllati. Questo determina sia quando i test possono iniziare sia quanto tempo richiederanno per essere completati. Il massimo che l'SQA può fare in questo modello è preparare gli script di test in anticipo, attendendo che venga raggiunta la Definition of Done (DoD) del team di sviluppo prima di eseguire i test.

Automazione della SQA: Un cambiamento nella strategia di test

L'unico modo per migliorare questo flusso è concentrarsi massicciamente sull'automazione. Tuttavia, non si tratta solo di automatizzare l'esecuzione dei test, ma richiede un cambiamento fondamentale nell'approccio ai test. Ciò include:

  • Ridefinire e riallineare gli obiettivi della QA del sistema.
  • Rivalutare come viene eseguita la convalida per soddisfare sia i requisiti di velocità che quelli normativi.
  • Riprogettare gli strumenti e i framework necessari per supportare efficacemente l'automazione.

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

Ciò significava che gli script di test venivano creati, automatizzati ed eseguiti in un ambiente in cui il codice di sviluppo viene regolarmente implementato, anche prima che venga raggiunto il DoD della funzionalità. Qui, i fallimenti dei test non indicano un difetto, ma piuttosto forniscono una visione precoce di quali parti della funzionalità non sono ancora implementate o completamente funzionanti.

Con pipeline di continuous delivery e una strategia di branching raffinata in atto, dove i rami delle funzionalità vengono uniti frequentemente nel ramo principale e distribuiti nel cloud, abbiamo configurato un ambiente dedicato in cui questi test di sistema automatizzati potessero essere eseguiti continuamente.

Feedback più rapido con Test Automatizzati

Questo approccio ha permesso alla QA del sistema di iniziare la convalida prima, rendendo i test più veloci e fornendo un feedback più rapido al team di sviluppo. Invece di aspettare che una funzionalità sia contrassegnata come completata, i test ora vengono eseguiti in parallelo con lo sviluppo, fornendo 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 di ripensare le strategie di test.

  • Passare dall'automazione basata sull'interfaccia utente → i test API sono diventati la priorità.
  • Passaggio allo sviluppo guidato dal comportamento (BDD) → Creazione di script di test insieme alle user story da includere nei criteri di accettazione.

Mentre la piena adozione del BDD fin dall'inizio della creazione delle user story è ancora un lavoro in corso, abbiamo migliorato la collaborazione tra i team SQA e di sviluppo, allineandoli precocemente nel processo.

Allineare la SQA con lo Sviluppo: L'Influenza delle Topologie di Team

Per raggiungere questo obiettivo, abbiamo applicato l'approccio del team specialistico da Team Topologies, istituendo il team SQA come team abilitante. Invece di essere una funzione di test separata e a valle, i membri del team SQA sono stati allineati strettamente con lo sviluppo per garantire che la creazione di casi di test automatizzati inizi presto e prosegua continuamente man mano che il codice viene sviluppato.

Un prerequisito chiave per questo approccio è disporre di un ambiente di test Cloud-based per eseguire test a livello di sistema prima di passare ad ambienti controllati. Sebbene ciò introduca costi infrastrutturali aggiuntivi, aumenta significativamente il flusso di lavoro dallo sviluppo alla SQA, rendendolo pronto per la distribuzione molto più velocemente.

Conclusione

Questo miglioramento rafforza un principio fondamentale del DevOps: affrontare la trasformazione considerando le competenze relative a Strumenti, Architettura e Persone, concentrandosi sul flusso. Automatizzando il QA del sistema, integrando i test in una fase precedente del ciclo e allineando i team in modo più efficace, abbiamo ridotto significativamente il collo di bottiglia tra sviluppo e convalida del sistema, accelerando i cicli di feedback e rendendo le implementazioni più fluide.

Conclusione della Serie

Mentre concludiamo la nostra serie DevOps for the Win, riflettiamo sul percorso dal caos degli strumenti e dei processi manuali a un'organizzazione più connessa, automatizzata e potenziata. Dalla definizione del nostro Triangolo DevOps nel Capitolo 1 all'istituzione dell'apprendimento basato sul feedback nel Capitolo 6, ogni capitolo si è basato sul precedente per guidare una trasformazione significativa.

Ecco un rapido riepilogo della nostra serie:

Questa trasformazione è in corso, ma con le basi che abbiamo costruito, siamo più attrezzati che mai per fornire valore in modo più rapido, sicuro e intelligente.

Grazie per averci accompagnato in questo percorso. Speriamo che la nostra storia ispiri la vostra evoluzione DevOps.

Sii curioso. Sii iterativo. E, soprattutto, rimani connesso.

Iscriviti al blog di Freyr