Fasi di test nei processi di integrazione e consegna continue

I tre team CI/CD devono incorporare i test nel ciclo di vita dello sviluppo del software in diverse fasi della pipeline CI/CD. Nel complesso, i test devono iniziare il prima possibile. La seguente piramide di test è un concetto illustrato da Mike Cohn nel libro Succeeding with Agile. La piramide mostra i vari test del software in relazione al loro costo e alla velocità con cui vengono eseguiti.

Piramide di test CI/CD

Gli unit test si trovano alla base della piramide. Sono i più veloci da eseguire e i meno costosi. Pertanto, gli unit test dovrebbero costituire la parte più importante della strategia di test. Per buona regola generale, dovrebbero corrispondere a circa il 70 percento della piramide di test. Gli unit test devono coprire quasi completamente il codice, poiché i bug rilevati in questa fase possono essere risolti in modo rapido ed economicamente vantaggioso.

I test del servizio, dei componenti e dell'integrazione si trovano ai livelli superiori della piramide rispetto agli unit test. Questi test richiedono ambienti dettagliati e, pertanto, sono più costosi in termini di requisiti di infrastruttura e prevedono un'esecuzione più lenta. I test delle prestazioni e della conformità si trovano al livello successivo. Richiedono ambienti di qualità di produzione e sono ancora più costosi. I test dell'interfaccia utente e di accettazione utente sono in cima alla piramide e richiedono ambienti di qualità di produzione.

Tutti questi test fanno parte di una strategia di test completa per garantire un software di alta qualità. Tuttavia, per la velocità del processo di sviluppo, l'accento è posto sul numero di test e sulla copertura nella metà inferiore della piramide.

Nelle sezioni seguenti sono descritte le fasi di CI/CD.

Configurazione dell'origine

All'inizio del progetto, è essenziale configurare una fonte in cui archiviare il codice non elaborato e le modifiche alla configurazione e allo schema. Nella fase di origine, scegli un repository del codice sorgente, ad esempio uno ospitato in GitHub o AWS CodeCommit.

Configurazione ed esecuzione delle build

L'automazione delle build è un passaggio essenziale del processo CI. Quando si configura l'automazione delle build, occorre innanzitutto scegliere lo strumento di compilazione giusto. Sono disponibili molti strumenti di compilazione, come ad esempio:

• Ant, Maven e Gradle per Java

• Make per C/C++

• Grunt per JavaScript

• Rake per Ruby

Lo strumento di compilazione più adatto alle tue esigenze dipende dal linguaggio di programmazione del progetto e dalle competenze del team. Dopo aver scelto lo strumento di compilazione, tutte le dipendenze devono essere chiaramente definite negli script di compilazione, insieme ai passaggi di compilazione. Questa è inoltre una best practice per il controllo delle versioni degli artefatti della build finali, che semplifica l'implementazione e il monitoraggio dei problemi.

Compilazione

Nella fase di compilazione, gli strumenti di compilazione trattano come input qualsiasi modifica al repository del codice sorgente, compilano il software ed eseguono i seguenti tipi di test:

Unit test: consentono di testare una sezione specifica di codice per assicurarsi che il codice si comporti come previsto. Gli unit test vengono eseguiti dagli sviluppatori del software durante la fase di sviluppo. In questa fase, è possibile applicare processi di analisi del codice statico, di analisi del flusso di dati, di copertura del codice e altri processi di verifica del software.

Analisi del codice statico: questo test viene svolto senza eseguire effettivamente l'applicazione dopo gli unit test e i test di compilazione. Questa analisi può aiutare a rilevare errori di codifica e falle di sicurezza e può inoltre garantire la conformità alle linee guida di codifica.

Gestione temporanea

Nella fase di gestione temporanea, vengono creati ambienti completi che rispecchiano il futuro ambiente di produzione. Vengono eseguiti i seguenti test:

Test di integrazione: consentono di verificare le interfacce tra i componenti rispetto alla progettazione del software. Il test di integrazione è un processo iterativo e facilita la creazione di interfacce solide e dell'integrità del sistema.

Test dei componenti: consentono di testare la trasmissione dei messaggi tra i vari componenti e i relativi risultati. Un obiettivo chiave di questi test potrebbe essere l'idempotenza nel test dei componenti. I test possono includere volumi di dati estremamente elevati o situazioni perimetrali e input anomali.

Test di sistema: consentono di testare il sistema in modo completo e di verificare se il software soddisfa i requisiti aziendali. Questi test potrebbero includere il test dell'interfaccia utente (UI), dell'API, della logica di back-end e dello stato finale.

Test delle prestazioni: consentono di determinare la reattività e la stabilità di un sistema durante il funzionamento con un particolare carico di lavoro. I test delle prestazioni vengono inoltre utilizzati per indagare, misurare, convalidare o verificare altri attributi di qualità del sistema, come scalabilità, affidabilità e utilizzo delle risorse. I tipi di test delle prestazioni possono includere test di carico, test di stress e spike test. I test delle prestazioni vengono utilizzati per il benchmark rispetto ai criteri predefiniti.

Test di conformità: consentono di verificare se la modifica del codice è conforme ai requisiti di una specifica e/o di una normativa non funzionale. Determinano se l'implementazione sta avvenendo nel rispetto degli standard definiti.

Test di accettazione dell'utente: consentono di convalidare il flusso aziendale completo. Questi test vengono eseguiti da un utente finale in un ambiente di gestione temporanea e consentono di verificare se il sistema soddisfa i requisiti della specifica dei requisiti. In genere, i clienti utilizzano metodologie di test alfa e beta in questa fase.

Produzione

Infine, dopo aver superato i test precedenti, la fase di gestione temporanea viene ripetuta in un ambiente di produzione. In questa fase, un test canary finale può essere completato implementando il nuovo codice solo su un piccolo sottoinsieme di server o anche su un solo server, o in una Regione AWS, prima di implementare il codice nell'intero ambiente di produzione. Le specifiche su come eseguire l'implementazione in modo sicuro nell'ambiente di produzione sono illustrate nella sezione Metodi di implementazione.

Nella sezione successiva viene illustrata la procedura di creazione della pipeline per incorporare le fasi e i test descritti sopra.