Flusso di lavoro dello sviluppatore end-to-end

Un moderno flusso di lavoro di sviluppo in Azure collega il controllo del codice sorgente, la CI/CD, l'infrastruttura dei contenitori e l'osservabilità in un inner loop fluido, dal commit del codice fino alla produzione osservabile. I componenti principali sono: GitHub (sorgente), GitHub Actions (pipeline di compilazione e distribuzione), Azure Container Registry (archivio delle immagini), Azure Container Apps (ambiente di esecuzione) e Application Insights (osservabilità). Ogni modifica passa automaticamente dal computer dello sviluppatore alla produzione in pochi minuti, con controlli di qualità a ogni passaggio.

Organizzi il codice in un repository GitHub usando una strategia di sviluppo basata sul trunk oppure GitFlow. Per la maggior parte dei microservizi, lo sviluppo basato sul trunk (branch di funzionalità di breve durata uniti quotidianamente a main) riduce i conflitti di integrazione e mantiene semplice la pipeline. Usi le regole di protezione dei branch su main per richiedere revisioni delle pull request e controlli CI superati prima dell'unione. Un file CODEOWNERS assicura che le modifiche ai servizi critici richiedano l'approvazione degli ingegneri senior del team competente.

La pipeline CI viene eseguita a ogni pull request. Un flusso di lavoro tipico è: estrazione del codice → ripristino delle dipendenze → esecuzione dei test unitari → esecuzione dei test di integrazione → compilazione dell'immagine Docker → push in Azure Container Registry. All'immagine viene assegnato come tag lo SHA del commit git per garantirne la tracciabilità. Usi l'autenticazione basata su OIDC da GitHub Actions ad Azure (tramite identità federata) per evitare di archiviare in GitHub i segreti del service principal di Azure: un equivalente dell'identità gestita per le pipeline CI.

Dopo il completamento della pipeline CI in seguito a un'unione in main, la pipeline CD distribuisce automaticamente nell'ambiente di staging. La pipeline aggiorna il tag dell'immagine della Container App con lo SHA appena compilato, attende che la nuova revisione diventi integra ed esegue smoke test sull'URL di staging. Gli smoke test verificano che gli endpoint API critici restituiscano le risposte previste. Se gli smoke test hanno esito negativo, la pipeline esegue il rollback reindirizzando il traffico in ingresso alla revisione precedente, senza alcun intervento manuale.

Dopo la convalida nello staging, la pipeline CD si mette in pausa su un gate di approvazione. Le protezioni degli ambienti di GitHub Actions consentono di configurare revisori obbligatori per l'ambiente production. La pipeline invia una notifica Slack all'ingegnere reperibile, che esamina i risultati dei test di staging, il diff e gli eventuali incidenti aperti prima di approvare. Solo dopo l'approvazione la pipeline procede distribuendo in produzione la stessa immagine identificata dallo SHA. Questo passaggio con supervisione umana è fondamentale per i servizi ad alto traffico o soggetti a normative.

Una volta eseguita la distribuzione in produzione, Application Insights offre visibilità in tempo reale. L'SDK di App Insights (o l'auto-strumentazione per i runtime supportati) tiene traccia di: tassi di richiesta, tassi di errore e latenza (i tre segnali fondamentali), chiamate alle dipendenze (a database, Service Bus e altre API) ed eccezioni con tracce dello stack complete. La Mappa delle applicazioni visualizza il modo in cui i servizi si chiamano tra loro ed evidenzia quali dipendenze contribuiscono maggiormente agli errori o alla latenza.

Usi le annotazioni di Application Insights per contrassegnare gli eventi di distribuzione nei grafici delle metriche. Quando viene creata un'annotazione di rilascio (tramite l'azione azure/appinsights-annotation di GitHub Actions), questa appare come una linea verticale in tutti i grafici delle metriche di App Insights. In questo modo è immediatamente evidente se un picco di latenza o un aumento del tasso di errore è correlato a una distribuzione recente, riducendo significativamente il tempo medio di diagnosi (MTTD) durante gli incidenti.

Per le pipeline più resilienti, implementi il rollback automatico. Dopo la distribuzione in produzione, la pipeline attende 10 minuti ed esegue una query in Application Insights per ottenere il tasso di errore. Se il tasso di errore supera una soglia configurabile (ad esempio, >5%), la pipeline esegue automaticamente il rollback aggiornando il traffico in ingresso della Container App in modo da indirizzare il 100% alla revisione precedente. Questo modello di distribuzione progressiva riduce il raggio d'azione di una distribuzione errata e consente ai team di distribuire con maggiore sicurezza anche modifiche complesse o sensibili.

Gli sviluppatori dovrebbero poter eseguire e testare localmente l'intero stack senza connettersi alle risorse Azure di produzione. Usi Azure Storage Emulator (Azurite) per l'archiviazione locale di BLOB e code, Cosmos DB Emulator per i test locali del database e Service Bus Emulator per la messaggistica locale. La variabile di ambiente AZURE_ENVIRONMENT=local può fare in modo che DefaultAzureCredential utilizzi stringhe di connessione che puntano agli emulatori, mentre lo stesso codice usa un'identità gestita in Azure. Docker Compose orchestra tutte le dipendenze locali con un unico comando docker compose up.

Integra la sicurezza in ogni fase del flusso di lavoro dello sviluppatore: Dependabot analizza le dipendenze vulnerabili nelle pull request; GitHub Advanced Security (scansione del codice con CodeQL) rileva vulnerabilità come l'iniezione SQL e i segreti codificati nel codice; Microsoft Defender for DevOps si integra con GitHub per mostrare le raccomandazioni di sicurezza di Azure insieme alle modifiche al codice; e la scansione delle vulnerabilità di ACR Defender controlla le immagini dei contenitori alla ricerca di CVE a livello di sistema operativo e applicazione dopo ogni push. I risultati relativi alla sicurezza vengono visualizzati come commenti nelle pull request, così possono essere risolti prima dell'unione.

Il flusso di lavoro completo per sviluppatori è un ciclo di feedback continuo: uno sviluppatore esegue il commit del codice, la CI compila e testa l'immagine del contenitore, l'immagine viene inserita in ACR con lo SHA del commit come tag, la CD esegue la distribuzione nello staging e gli smoke test, una persona approva la distribuzione in produzione, la pipeline distribuisce in produzione e crea un'annotazione di rilascio, quindi Application Insights monitora i tassi di errore eseguendo un rollback automatico se le soglie vengono superate. L'infrastruttura come codice (Bicep o Terraform) nello stesso repository garantisce che la pipeline, la Container App e la configurazione del monitoraggio siano tutte sottoposte al controllo della versione insieme al codice dell'applicazione.

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

In questa lezione ha imparato che il flusso di lavoro end-to-end per sviluppatori collega il controllo del codice sorgente GitHub, la CI/CD di GitHub Actions, Azure Container Registry, Container Apps e Application Insights; le annotazioni di rilascio correlano le distribuzioni alle variazioni delle metriche per diagnosticare più rapidamente gli incidenti; e il rollback automatico basato sulle query del tasso di errore riduce il raggio d'azione delle distribuzioni errate. Ora passeremo alla preparazione dell'esame con un ripasso completo dei concetti cloud e dell'architettura Azure.