Automazione dei test e pipeline di recapito
- 5 minuti
Sono state illustrate la distribuzione e il recapito continui di software e servizi, ma le due procedure in realtà fanno parte di una triade. Le procedure DevOps sono finalizzate a ottenere l'integrazione, il recapito e la distribuzione continui. Queste procedure vengono in genere sviluppate in questo ordine, ognuna dipendente da quella precedente.
A questo punto è giunto il momento di eseguire un backup e discutere della prima di queste, l'integrazione. Questa operazione fa parte del processo di sviluppo che precede la distribuzione. DevOps consiglia una procedura di sviluppo in cui i membri del team integrano spesso il codice in un repository condiviso contenente una codebase singolare "principale" o "trunk". L'obiettivo è quello di fare in modo che tutti contribuiscano al codice che verrà distribuito anziché lavorare alla propria copia e riunire il tutto solo all'ultimo momento.
I test automatizzati possono quindi verificare l'integrazione di ogni membro del team. Questo test aiuta a determinare che il codice sia integro dopo ogni modifica e aggiunta. Il test fa parte di ciò che viene comunemente chiamato pipeline. La parte restante di questa unità è incentrata sui test integrati e sulle pipeline di recapito.
Pipeline di recapito continuo
Per comprendere il ruolo del test automatizzato nel modello di distribuzione di recapito continuo, occorre esaminare il punto in cui si inserisce nella pipeline di recapito. Una pipeline di recapito continuo è l'implementazione del set di passaggi che il codice attraversa quando vengono apportate modifiche durante il processo di sviluppo prima della distribuzione nell'ambiente di produzione. Ecco una rappresentazione grafica dei passaggi di esempio in una pipeline di recapito semplificata:
Passa attraverso questa procedura dettagliata passo dopo passo:
Un'istanza della pipeline ha inizio quando viene eseguito il commit delle modifiche del codice o dell'infrastruttura in un repository di codice, ad esempio usando una richiesta pull.
Successivamente, gli unit test vengono eseguiti, spesso seguiti da test di integrazione o end-to-end. I risultati vengono comunicati nuovamente allo sviluppatore che ha aperto la richiesta pull.
In questa fase, il codice nel repository viene spesso analizzato per individuare segreti, vulnerabilità e configurazioni errate.
Quando tutto è stato estratto, il codice viene compilato e preparato per la distribuzione.
Successivamente, il codice viene distribuito in un ambiente di test. Un revisore può ricevere una notifica della nuova distribuzione in modo che possa esaminare la soluzione di preproduzione. Il revisore approva o rifiuta quindi la promozione all'ambiente di produzione, avviando la parte finale del processo di distribuzione che rilascia il codice in produzione.
In questa pipeline è possibile visualizzare il delineamento tra integrazione e distribuzione. I marcatori evidenziati indicano alcune posizioni logiche in cui è possibile arrestare la pipeline tramite logica e automazione incluse o potenzialmente anche l'intervento umano.
Strumenti per l'integrazione e il recapito continui: Azure Pipelines e GitHub Actions
Per usare l'integrazione continua e il recapito continuo, sono necessari gli strumenti appropriati. Microsoft offre due opzioni CI/CD di prima parte per la compilazione e la distribuzione in Azure: Azure Pipelines (parte di Azure DevOps) e GitHub Actions. Entrambi possono automatizzare la compilazione e il test coerente del codice ed entrambi possono essere distribuiti in servizi Azure, macchine virtuali e altre destinazioni nel cloud e in locale. Molti team adottano GitHub Actions quando il codice sorgente vive già in GitHub, mentre Azure Pipelines rimane una scelta solida per i team standardizzati in Azure DevOps.
Il resto di questa unità è incentrato sulle Azure Pipelines, ma GitHub Actions usa idee di alto livello simili anche se la terminologia è diversa. In GitHub Actions, i flussi di lavoro contengono processi e passaggi; le azioni raggruppano automazione riutilizzabile; i runner eseguono il lavoro; e gli ambienti possono proteggere i rilasci.
L'input in una pipeline (il codice o le configurazioni) si trova in un sistema di controllo della versione, ad esempio GitHub o un altro provider Git.
Azure Pipelines viene eseguito in ambiente di calcolo, ad esempio una macchina virtuale o un contenitore, e offre agenti di compilazione ospitati Microsoft che eseguono Windows, Linux e macOS. È anche possibile registrare i propri agenti ospitati autonomamente quando è necessario il controllo completo sull'ambiente di compilazione. Offre anche l'integrazione con plug-in di test, sicurezza e qualità del codice. Infine, è facilmente estendibile, in modo da poter portare la propria automazione in Azure Pipelines.
Le pipeline vengono definite usando la sintassi YAML archiviata insieme al codice in un repository Git. Le pipeline YAML sono l'approccio consigliato per i nuovi progetti. Un'interfaccia utente classica in Azure DevOps è disponibile anche per le pipeline legacy, ma la maggior parte delle nuove funzionalità (inclusi i processi contenitore e molte funzionalità avanzate) è solo YAML. Le pipeline forniscono anche modelli che è possibile usare per creare facilmente pipeline, ad esempio un modello per un'immagine Docker o un progetto di Node.js. È anche possibile riutilizzare un file YAML esistente.
I passaggi di base per la configurazione di una pipeline sono:
- Configurare Azure Pipelines per utilizzare il tuo repository Git.
- Definire la compilazione modificando il file azure-pipelines.yml (o, per le pipeline legacy, usando l'editor classico).
- Eseguire il push del codice nel repository di controllo della versione. Questa azione attiva la pipeline per la compilazione e il test del codice.
Una volta che il codice è stato aggiornato, compilato e testato, è possibile distribuirlo nella destinazione desiderata.
costruzione di pipeline di Azure
Le pipeline sono strutturate in:
Processi: un processo è un raggruppamento di attività o passaggi eseguiti in un singolo agente di compilazione. Un processo è il componente di lavoro più piccolo di cui è possibile pianificare l'esecuzione. Tutti i passaggi in un processo vengono eseguiti in sequenza. Questi passaggi possono includere qualsiasi azione necessaria, tra cui la creazione o la compilazione di software, la preparazione dei dati di esempio per i test, l'esecuzione di test specifici e così via.
Fasi: una fase è un raggruppamento logico di attività correlate.
Ogni pipeline ha almeno una fase. Usare più fasi per organizzare la pipeline in divisioni principali e contrassegnare i punti della pipeline in cui è possibile sospendere ed eseguire i controlli.
Le pipeline possono essere semplici o complesse a seconda delle esigenze. Per esercitazioni sulla costruzione e sull'uso della pipeline, vedere il percorso di apprendimento Build applications with Azure DevOps.
Tracciabilità dell'ambiente
C'è un altro aspetto delle pipeline correlato all'affidabilità che vale la pena menzionare. Le pipeline possono essere create in modo da correlare gli elementi in esecuzione nell'ambiente di produzione con un'istanza di compilazione specifica. Idealmente, dovrebbe essere possibile tracciare una compilazione a una richiesta pull o a una modifica del codice specifica. Questa tracciabilità è preziosa durante un evento imprevisto e successivamente durante la revisione post-evento imprevisto quando si sta tentando di identificare quale modifica ha contribuito a un problema. Alcuni sistemi CI/CD (ad esempio Azure Pipelines e GitHub Actions) semplificano questa correlazione, mentre altri richiedono di costruire manualmente una pipeline che propaga un ID di compilazione in ogni fase.