Creazione di una pipeline CI con Azure Pipelines

La Continuous Integration (CI) è la pratica di unire frequentemente le modifiche al codice in un branch condiviso, attivando automaticamente una compilazione e un'esecuzione dei test a ogni unione. L'obiettivo è rilevare tempestivamente gli errori di integrazione, prima che si trasformino in problemi più estesi e difficili da risolvere. Una buona pipeline CI compila il codice, esegue i test unitari, misura la code coverage, esegue l'analisi statica e produce un artifact distribuibile in pochi minuti. Azure Pipelines fornisce il motore di automazione per questa pratica.

Le pipeline CI di Azure Pipelines sono definite in un file azure-pipelines.yml nella radice del repository. Il file YAML specifica i trigger (quando eseguire la pipeline), un pool (quale tipo di agent usare) e una gerarchia di stages, jobs e steps. Per impostazione predefinita, gli stages vengono eseguiti in sequenza. I jobs all'interno di uno stage vengono eseguiti in parallelo per impostazione predefinita. Gli steps all'interno di un job vengono eseguiti in sequenza. Questa struttura offre un controllo dettagliato sul flusso di esecuzione della pipeline.

Azure Pipelines supporta diversi tipi di trigger. I trigger dei branch eseguono la pipeline quando il codice viene inviato a branch specifici. I trigger delle pull request (trigger PR) vengono attivati quando una PR viene aperta o aggiornata rispetto ai branch di destinazione: sono essenziali per convalidare il codice prima dell'unione. I trigger pianificati vengono eseguiti a un'ora prestabilita (ad esempio, per le build notturne). I trigger delle pipeline concatenano più pipeline. Specifichi trigger: none per disabilitare le esecuzioni automatiche e consentire solo l'esecuzione manuale.

Gli steps della pipeline sono costituiti da script (comandi bash o PowerShell) oppure da tasks (unità predefinite e parametrizzate disponibili nel marketplace di Azure DevOps). Task come NodeTool@0, DotNetCoreCLI@2 e Maven@3 incapsulano operazioni di build comuni. Utilizzi displayName in ogni step per ottenere log della pipeline leggibili. Ogni step viene eseguito in sequenza e la pipeline ha esito negativo se uno step restituisce un codice diverso da zero, a meno che non imposti continueOnError: true.

Dopo aver eseguito i test, pubblichi i risultati in Azure DevOps utilizzando il task PublishTestResults. Azure Pipelines analizza i file dei risultati in formato JUnit, NUnit, XUnit o VSTest e mostra nell'interfaccia dell'esecuzione della pipeline il numero di test superati e non superati, la durata dell'esecuzione e i dettagli dei singoli test. La cronologia dei test viene monitorata nel tempo, consentendo di individuare test instabili e regressioni. Questo è essenziale per avere visibilità sulla qualità del codice all'interno del team.

Pubblichi i report di code coverage affinché Azure Pipelines mostri le percentuali e gli andamenti della coverage nell'interfaccia della pipeline. Il task PublishCodeCoverageResults accetta report nei formati Cobertura o JaCoCo. Lo abbini ai controlli sulla branch coverage: configuri una soglia minima e interrompa la build se la coverage scende al di sotto di tale soglia. Gli andamenti della coverage aiutano a individuare quando viene aggiunto nuovo codice senza test corrispondenti.

Memorizzi la configurazione della pipeline in variables definite a livello di pipeline, stage o job nel file YAML. Per i valori sensibili (chiavi API, password), utilizzi secret variables: le imposti nella libreria della pipeline (interfaccia utente) o nei gruppi di variabili e vi faccia riferimento nel file YAML. I variable groups sono raccolte riutilizzabili di variabili condivise tra più pipeline. Colleghi un gruppo di variabili ad Azure Key Vault per sincronizzare automaticamente i secret da Key Vault alle variabili della pipeline.

Dopo una build completata correttamente, impacchetti l'output in un pipeline artifact, così che gli stages successivi, ad esempio quello di distribuzione, possano accedervi. Utilizzi PublishPipelineArtifact per caricare i file dall'agent di build nell'archiviazione degli artifact di Azure DevOps. In uno stage o job successivo, utilizzi DownloadPipelineArtifact per recuperare l'artifact. In questo modo il job di build è disaccoppiato dai job di distribuzione, che possono essere eseguiti su agent diversi o in stages differenti.

Esegua le attività indipendenti in parallelo definendo più jobs all'interno di uno stage. Ad esempio, esegua contemporaneamente i test unitari e la scansione di sicurezza invece che in sequenza. I job paralleli richiedono minuti di build separati, ma possono ridurre notevolmente la durata complessiva della pipeline. Utilizzi la proprietà dependsOn per fare in modo che un job attenda il completamento di uno o più job prima di avviarsi, creando un grafo delle dipendenze all'interno dello stage.

Colleghi la pipeline CI a una branch policy in Azure Repos, affinché venga eseguita automaticamente come build validation check sulle pull request indirizzate a main. L'unione è bloccata finché la pipeline non viene completata correttamente. Combini più controlli: la pipeline CI deve avere esito positivo, almeno 2 revisori devono approvare, tutti i commenti devono essere risolti e deve esistere un work item collegato. In questo modo si crea un quality gate che impedisce di unire codice non funzionante al branch principale.

Al termine dell'esecuzione di una pipeline, esamini i risultati nel portale di Azure DevOps. La scheda Summary mostra l'esito complessivo e i tempi. La scheda Tests elenca tutti i risultati dei test e consente di filtrarli in base all'esito. La scheda Code Coverage mostra la percentuale di coverage ed evidenzia le righe non coperte. Faccia clic su un job per visualizzare l'output del log step by step. Le pipeline non riuscite mostrano lo step che ha causato l'errore evidenziato in rosso, insieme all'output completo dell'errore per una diagnosi rapida.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che Azure Pipelines YAML definisce pipeline CI con stages, jobs e steps per la build, i test e la creazione degli artifact; i trigger PR e le branch policy applicano quality gate che bloccano l'unione di codice non funzionante; e i task PublishTestResults e PublishCodeCoverageResults rendono visibile la qualità dei test all'interno del team. Prossimamente vedremo la continuous deployment verso Azure.