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

In Capitolo 5: Diramazioni e distribuzione continuaabbiamo analizzato come i rami di breve durata e una piattaforma centralizzata di distribuzione continua (CD) us aiutato ad accelerare la consegna e a ridurre l'attrito dell'integrazione. Questi cambiamenti hanno migliorato notevolmente il flusso di codice verso la produzione, ma per completare veramente il ciclo di feedback DevOps, avevamo bisogno di altro.

Il capitolo 6, il segmento finale della nostra serie DevOps for the Win, si addentra nell'ultimo ma fondamentale pilastro della nostra trasformazione: Automazione e feedback. Se il deployment continuo us ha aiutato a rilasciare più velocemente, l'automazione e il feedback us hanno aiutato a imparare più rapidamente, us di migliorare continuamente con fiducia.

Perché automazione e feedback sono importanti

In qualsiasi trasformazione DevOps, la velocità senza sicurezza è una ricetta per il disastro. Con l'aumento della frequenza di distribuzione, l'esigenza di controlli automatizzati e di feedback in tempo reale è diventata cruciale, non solo per garantire la qualità, ma anche per il potere decisionale del team.

L'automazione e i sistemi di feedback forniscono ai team:

  • Individuazione precoce dei problemi prima che reach produzione
  • Fiducia nei cambiamenti, grazie a una convalida ripetibile e affidabile
  • Metriche approfondite per comprendere la salute del sistema e l'impatto sugli utenti

È la differenza tra volare alla cieca e volare con un cruscotto.

Dopo aver migliorato la velocità di sviluppo, la nostra attenzione si è concentrata sull'identificazione dei colli di bottiglia nel ciclo di feedback una volta che il team di sviluppo ha contrassegnato il lavoro come "finito". In questo caso, la misura principale del flusso era la velocità con cui il lavoro completato poteva essere distribuito in produzione.

Il Lead Time for Change e la Deployment Frequency sono parametri fondamentali per misurare l'efficienza con cui il lavoro si muove all'interno del 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 sistema QA

Nella maggior parte dei settori, 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 es. verifica della rete, test delle prestazioni)
  • Artefatti di convalida → Rapporti di collaudo del sistema, IQ (Installation Qualification), OQ (Operational Qualification) e PQ (Performance Qualification)

Queste attività devono essere eseguite 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.

I nostri dashboard mostravano che il tempo necessario per portare il lavoro completato allo stato di pronto per la produzione stava aumentando, con un maggior numero di lavori in attesa che la SQA iniziasse i test. Seguendo il nostro approccio fondamentale al miglioramento del flusso, questo era un problema che dovevamo risolvere prima che qualsiasi altra ottimizzazione DevOps potesse mostrare un valore reale.

Sfide chiave nel flusso da sviluppo a SQA

Il miglioramento del flusso di lavoro dallo sviluppo alla QA del sistema ha comportato due sfide principali:

  1. Il ritardo nell'avvio delle attività di SQA
  2. Velocità di esecuzione della convalida del sistema

Se i test SQA sono principalmente manuali, possono iniziare solo quando il codice è completamente sviluppato e distribuito in ambienti controllati. Ciò determina sia il momento in cui i test possono iniziare sia il tempo necessario per completarli. La cosa migliore che la SQA può fare in questo modello è preparare gli script di test in anticipo, aspettando che il team di sviluppo raggiunga la Definizione di Fatto (DoD) prima di eseguire i test.

Automatizzare la SQA: Un cambiamento nella strategia di test

L'unico modo per migliorare questo flusso è concentrarsi in modo massiccio sull'automazione. Tuttavia, non si tratta solo di automatizzare l'esecuzione dei test: è necessario un cambiamento fondamentale nel modo in cui i test vengono affrontati. Questo include:

  • Ridefinire e riallineare gli obiettivi della QA di sistema.
  • Rivalutare il modo in cui viene eseguita la convalida per soddisfare sia la velocità che i requisiti normativi.
  • Ripensare gli strumenti e i framework necessari per supportare efficacemente l'automazione.

Uno dei principali cambiamenti di mentalità è stato il passaggio dai test per confermare che il software sviluppato funziona → ai test per guidare lo sviluppo.

Ciò significava creare script di test, automatizzarli ed eseguirli in un ambiente in cui il codice di sviluppo viene regolarmente aggiornato, anche prima che venga raggiunto il DoD della funzionalità. In questo caso, 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 le pipeline di consegna continua e una raffinata strategia di ramificazione, in cui i rami delle funzionalità vengono fusi frequentemente nel ramo principale e distribuiti nel cloud, abbiamo creato un ambiente dedicato in cui questi test di sistema automatizzati potessero essere eseguiti continuamente.

Feedback più rapido con i test automatizzati

Questo approccio ha permesso al QA di sistema di iniziare prima la convalida, rendendo i test più rapidi e fornendo un feedback più veloce al team di sviluppo. Invece di aspettare fino a quando una funzionalità viene 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 un ripensamento delle strategie di test.

  • Allontanarsi dall'automazione basata sull'interfaccia utente → il test delle API è diventato la priorità.
  • Passaggio al Behavior-Driven Development (BDD) → Creazione di script di test insieme alle storie utente da includere nei criteri di accettazione.

Sebbene l'adozione completa del BDD fin dall'inizio della creazione delle storie utente sia ancora un lavoro in corso, abbiamo migliorato la collaborazione tra i team di SQA e di sviluppo, allineandoli fin dalle prime fasi del processo.

Allineare la SQA con lo sviluppo: L'influenza delle topologie dei team

Per raggiungere questo obiettivo, abbiamo applicato l'approccio del team specializzato di Team Topologies, configurando il team SQA come un 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 di automazione inizi presto e venga eseguita continuamente durante lo sviluppo del codice.

Un prerequisito fondamentale per questo approccio è disporre di un ambiente di test cloud-based per eseguire test a livello di sistema prima di passare ad ambienti controllati. Se da un lato questo introduce costi infrastrutturali aggiuntivi, dall'altro aumenta in modo significativo il flusso di lavoro dallo sviluppo alla SQA, rendendolo pronto per la distribuzione molto più rapidamente.

Conclusione

Questo miglioramento rafforza un principio fondamentale di DevOps: affrontare la trasformazione considerando le competenze di strumenti, architettura e persone e concentrandosi sul flusso. Automatizzando la QA del sistema, integrando i test all'inizio del ciclo e allineando i team in modo più efficace, abbiamo ridotto in modo significativo il collo di bottiglia tra lo sviluppo e la convalida del sistema, accelerando i cicli di feedback e rendendo più fluide le distribuzioni.

Conclusione della serie

Per concludere la nostra serie DevOps for the Win, riflettiamo sul viaggio che ci ha portato 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 alla creazione di un apprendimento guidato dal feedback nel Capitolo 6, ogni capitolo si è basato sul precedente per guidare una trasformazione significativa.

Ecco un breve riassunto della nostra serie:

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

Grazie per averci seguito in questo viaggio. Speriamo che la nostra storia ispiri la vostra evoluzione DevOps.

Rimanere curiosi. Rimanete iterativi. E soprattutto, rimanete connessi.

Iscriviti al blog di Freyr