Distribuzione continua in Azure

La Continuous Deployment (CD) rilascia automaticamente in produzione ogni modifica che supera i test CI, senza intervento manuale. La Continuous Delivery è la variante più prudente: automatizza la distribuzione fino a un ambiente di staging e richiede l'approvazione di una persona prima della produzione. Entrambe le pratiche si basano sulla stessa infrastruttura di pipeline. In Azure Pipelines, la CD viene implementata aggiungendo stages di distribuzione dopo lo stage CI, indirizzati agli ambienti Azure con gli eventuali quality gate di approvazione.

Una pipeline CI/CD completa comprende almeno tre stages: Build (compilazione, test e pubblicazione dell'artifact), Deploy to Staging (distribuzione dell'artifact in uno slot non di produzione) e Deploy to Production (scambio dello slot o distribuzione dopo l'approvazione). Gli stages passano l'artifact allo stage successivo tramite l'archiviazione degli artifact della pipeline. Lo stage di staging esegue automaticamente test di integrazione o smoke test; lo stage di produzione attende l'approvazione manuale prima di procedere.

Utilizzi job deployment (non il normale job) per gli stages di distribuzione. I job di deployment supportano strategie di distribuzione (runOnce, rolling, canary), tengono traccia della cronologia delle distribuzioni per ogni ambiente e devono fare riferimento agli Environments di Azure DevOps. Un ambiente registra quali esecuzioni della pipeline vi hanno effettuato una distribuzione, quale versione è attualmente attiva e fornisce in un'unica dashboard i quality gate di approvazione, i controlli e lo stato di integrità delle risorse.

Il task AzureWebApp@1 distribuisce un'applicazione Web in Azure App Service. Supporta la distribuzione in uno slot specifico (ad esempio, staging) e la distribuzione di pacchetti ZIP, immagini Docker o file JAR/WAR. Dopo la distribuzione in uno slot di staging, utilizzi il task AzureAppServiceManage@0 per swap dello slot di staging in produzione: è il modello di distribuzione preferito per App Service quando si vuole evitare l'interruzione del servizio.

Dopo la distribuzione in staging, esegua gli smoke test, cioè un insieme minimo di test che verifica che la distribuzione sia riuscita e che l'applicazione risponda correttamente. Gli smoke test chiamano generalmente gli endpoint API principali e verificano i codici di stato e il contenuto della risposta attesi. Se gli smoke test hanno esito negativo, la pipeline si interrompe prima dello scambio verso la produzione o della richiesta di approvazione, impedendo che un rilascio non funzionante raggiunga gli utenti.

Aggiunga quality gate di approvazione agli Environments di Azure DevOps per richiedere un'approvazione manuale prima di procedere con le distribuzioni. Acceda alle impostazioni dell'ambiente e aggiunga le approvazioni, specificando gli utenti o i gruppi che devono approvare. Quando la pipeline raggiunge un job di deployment indirizzato a quell'ambiente, si mette in pausa e invia una notifica via e-mail. Gli approvatori possono visualizzare i dettagli della distribuzione e approvare o rifiutare la richiesta nel portale Azure DevOps o tramite il link contenuto nell'e-mail di notifica.

Distribuisca le applicazioni containerizzate in AKS utilizzando il task KubernetesManifest@0. Questo task applica i manifest YAML di Kubernetes al cluster, con supporto integrato per imagePullSecrets e le distribuzioni canary. Si connetta al cluster AKS utilizzando una connessione al servizio Kubernetes configurata in Azure DevOps. Il task utilizza kubectl apply internamente e attende il completamento del rollout prima di contrassegnare lo step come completato correttamente.

Assegni alle immagini dei container il build ID ($(Build.BuildId)) o lo SHA del commit Git ($(Build.SourceVersion)), così da poter sempre risalire dal container in esecuzione all'esatta revisione del codice da cui è stato creato. Eviti di usare il tag latest in produzione: Kubernetes lo memorizza nella cache e potrebbe non scaricare la nuova versione. Memorizzi il tag specifico dell'immagine come variabile della pipeline e lo inserisca nei manifest Kubernetes al momento della distribuzione utilizzando envsubst o sed.

Definisca una strategia di rollback per le distribuzioni in produzione, così potrà ripristinare rapidamente il servizio dopo un rilascio problematico. Per App Service, il rollback consiste nel riportare lo slot di produzione alla versione precedente dello staging. Per AKS, utilizzi kubectl rollout undo. Crei una pipeline di rollback dedicata oppure aggiunga un processo di rollback manuale che possa essere avviato dal portale Azure DevOps. Documenti la procedura di rollback e la eserciti regolarmente: un rollback non testato non è un rollback.

Dopo ogni distribuzione in produzione, esegua automaticamente un controllo di monitoraggio per verificare che la nuova versione funzioni correttamente. Utilizzi il controllo di pipeline AzureMonitor@1 per interrogare le metriche di Azure Monitor: se il tasso di errori aumenta dopo la distribuzione, blocchi l'avanzamento della pipeline e avvii un rollback. Invii notifiche sulle distribuzioni a Microsoft Teams o Slack tramite attività webhook, così il team saprà quando una distribuzione è completata e quale versione è attiva.

Segua queste best practice per la distribuzione continua: distribuisca frequentemente (lotti di piccole dimensioni riducono i rischi), utilizzi i feature flag per separare la distribuzione dal rilascio, automatizzi tutti i quality gate prima della produzione, utilizzi uno staging simile alla produzione così che le differenze non nascondano i bug, monitori le finestre di distribuzione con controlli automatici dello stato e disponga sempre di un piano di rollback testato. Una pipeline CD matura rende la distribuzione un'operazione ordinaria anziché un'attività ad alto stress.

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

In questa lezione ha imparato che: le pipeline YAML multi-stage concatenano le fasi Build, Staging e Production trasferendo gli artifact, i processi di distribuzione con Environments consentono di configurare gate di approvazione e monitorare le distribuzioni e gli smoke test dopo la distribuzione nello staging impediscono ai rilasci non funzionanti di raggiungere la produzione. Ora esamineremo GitHub Actions in Azure.