Microsoft AZ-400: Gestione dei rilasci e strategie di distribuzione — Guida allo studio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione dei rilasci su Azure si basa su una delivery ripetibile e governata da policy che protegge la disponibilità accelerando al contempo il feedback. Padroneggiare le strategie di deployment, le validazioni con gate, l’esposizione basata su ring e i dark launch con feature flag consente ai team di rilasciare in modo continuo senza sacrificare la sicurezza. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager e Azure App Configuration forniscono una toolchain coesa per la delivery progressiva, l’orchestrazione multi-ambiente e un controllo delle modifiche auditabile. Questa sezione spiega quando e come utilizzare ciascuna funzionalità, come collegarle tra loro e quali pratiche di rollback e documentazione sono previste nelle pipeline di livello production.

Strategie di Deployment e Delivery Progressiva

Il deployment blue-green (red/black) distribuisce la nuova versione in un ambiente parallelo (green) mentre quello attuale (blue) gestisce il traffico. Su Azure App Service, gli slot di deployment implementano il blue-green: si effettua il deploy nello slot di staging, si esegue il warm-up e poi si effettua uno swap degli slot. Il rollback è istantaneo eseguendo uno swap inverso, motivo per cui il blue-green è l’opzione di rollback più veloce. Abbinare lo swap degli slot con la funzione “Swap with preview” per validare i binding e le impostazioni dell’app prima che il traffico venga spostato.

Il deployment canary distribuisce prima a una piccola fetta di utenti, per poi aumentare progressivamente il traffico se lo stato di integrità (health) si mantiene stabile. Su Azure, si implementa il canary con:

Il routing ponderato di Azure Front Door per suddividere il traffico tra backend vecchi e nuovi a livello di applicazione, con health probe e WAF.
Gli endpoint ponderati di Azure Traffic Manager per canary globali basati su DNS, quando è necessario un controllo a livello di regione.
Canary su AKS tramite Ingress (es. annotazioni canary di NGINX) o traffic splitting di una service mesh. I gate dovrebbero valutare i budget di errore, i percentili di latenza e la saturazione prima di procedere.

Gli aggiornamenti continui (rolling update) sostituiscono le istanze gradualmente, evitando il costo di una doppia flotta. In AKS, configurare rollingUpdate con maxSurge e maxUnavailable; assicurarsi che readiness/liveness probe e PDB proteggano la disponibilità. Per i VM Scale Sets, utilizzare policy di aggiornamento continuo (rolling upgrade) con health probe applicative. Il rolling è economico ma più lento da ripristinare in caso di regressioni sistemiche rispetto al blue-green.

I feature flag disaccoppiano il rilascio dal deploy. Il dark launching distribuisce percorsi di codice disabilitati di default, mettendo alla prova l’infrastruttura senza esporre le funzionalità. Usare i flag per controllare migrazioni onerose, svelare progressivamente l’interfaccia utente e disattivare rapidamente comportamenti problematici. Questo integra i deployment canary e basati su ring: si distribuisce su larga scala, per poi abilitare progressivamente.

Il deployment basato su ring formalizza l’esposizione progressiva attraverso coorti di utenti. Definire i ring, come R0 (interni), R1 (clienti canary), R2 (una regione) e R3+ (globale). I criteri di avanzamento devono essere oggettivi: conformità agli SLO, nessun incidente di tipo Sev2+ e KPI di business accettabili. Abbinare i ring con il traffic shifting (Front Door/Traffic Manager), controlli sull’ambiente e gate di approvazione per fermare o effettuare un rollback anticipato.

Azure Front Door versus Traffic Manager per lo spostamento progressivo del traffico: Azure Front Door opera a livello 7 con modifiche istantanee, health probe, affinità di sessione, routing basato su percorso e suddivisione ponderata del traffico: ideale per canary a livello di applicazione e test A/B. Traffic Manager opera a livello DNS; è più indicato per il geo-routing, il failover cross-cloud o i canary a livello di regione, ma presenta considerazioni legate al TTL del DNS e non offre funzionalità a livello di applicazione.

Ambienti, Approvazioni e Gate

Azure Deployment Environments standardizza il provisioning di ambienti di sviluppo/test con dei guardrail. Le definizioni di ambiente sono template infrastructure-as-code (Bicep/ARM/Terraform) che descrivono stack ripetibili. Le definizioni risiedono in cataloghi (repository Git registrati con il servizio), abilitando blueprint di ambiente versionati e individuabili. Gli sviluppatori creano in modalità self-service istanze di dev/test vincolate da policy aziendali (quote, RBAC, networking), eliminando configurazioni “snowflake” e allineando gli ambienti inferiori con la topologia di produzione.

Le approvazioni stabiliscono controlli con intervento umano (human-in-the-loop) dove necessario. In Azure Pipelines:

Le approvazioni pre-deployment bloccano uno stage finché gli approvatori designati non danno il loro consenso. Utilizzare per transizioni ad alto rischio, ad esempio dal staging alla produzione o per l’escalation di ring oltre il canary.
Le approvazioni post-deployment confermano le attività di validazione (approvazione UAT, passaggi di audit) prima che il rilascio sia contrassegnato come completo.
Configurare i timeout di approvazione in modo che le richieste scadano automaticamente; le approvazioni scadute causano il fallimento dello stage e prevengono deviazioni (drift) incontrollate. Richiedere più approvatori o approvazioni in sequenza quando è necessaria la separazione dei compiti. Applicare le approvazioni ad ambienti e connessioni ai servizi tramite “Approvals and checks” per una governance coerente.

I gate di rilascio impongono la presenza di prove oggettive prima della promozione. Azure Pipelines supporta controlli (check) come:

Controlli di Azure Monitor che interrogano metriche o alert (es. nessun alert Sev2 attivo, tasso di errore al di sotto della soglia, latenza p95 inferiore all’obiettivo). I gate rieseguono la valutazione a un intervallo definito fino al successo/fallimento o al timeout.
Controlli ‘Invoke REST API’ per chiamare servizi di qualità esterni, test di carico o endpoint di conformità interni. Analizzare le risposte e bloccare se i criteri non sono soddisfatti.
Controlli ‘Work item query’ per garantire che task, bug o richieste di modifica necessari siano negli stati corretti prima del rilascio (es. tutti i difetti “Must Fix” risolti). Utilizzare query con ambito limitato al rilascio o all’intervallo di commit.

Implementare i gate ai confini dei ring e durante il canary per passare da decisioni di promozione soggettive a decisioni misurabili.

Pipeline multi-ambiente, variabili e dipendenze

Progettare pipeline YAML multi-stage con dipendenze esplicite e scope per ambiente. Utilizzare job di deployment con blocchi di strategia (runOnce, rolling, canary) per modellare un rollout progressivo e includere hook per preDeploy, routeTraffic, postRouteTraffic e on: failure per il rollback automatico. Gli stage dovrebbero dichiarare dependsOn e conditions in modo che gli ambienti successivi vengano eseguiti solo dopo che i precedenti hanno superato gate e approvazioni.

Gestire la configurazione specifica per ambiente tramite:

Gruppi di variabili con scope per ambiente, collegati ad Azure Key Vault per i segreti. Fare riferimento ai gruppi per ogni stage e mantenere i valori sensibili fuori dal controllo di versione.
Template YAML e parametri di runtime per standardizzare i deployment tra i servizi e passare valori specifici dell’ambiente (stringhe di connessione, valori predefiniti dei feature flag, pesi di Front Door).
Task di tokenizzazione o trasformazione per appsettings e manifest di Kubernetes, garantendo una configurazione come codice senza deviazioni (drift-free).

Per i deployment in più ambienti, preferire artefatti immutabili con promozione (build una volta, deploy molteplici). Collegare i work item ai commit e alle build per mantenere la tracciabilità mentre lo stesso artefatto passa da dev a prod, consentendo note di rilascio e audit accurati.

Strategie di rollback e considerazioni sui database

Pianificare i rollback prima del rilascio:

Il rollback automatico utilizza segnali di integrità (health signal) per ripristinare senza intervento umano. In AKS, impostare maxSurge/maxUnavailable in modo conservativo e abilitare il rollback automatico sui rollout falliti; usare kubectl rollout undo o affidarsi agli hook di fallimento della strategia di deployment per attivare un ReplicaSet precedente. In Azure App Service, lo slot swap inverso è istantaneo; abbinarlo a health check e gate di deployment per decidere automaticamente.
Il rollback manuale è appropriato quando il ripristino richiede il giudizio di un operatore (rischio sui dati, fallimento parziale). Fornire task di pipeline eseguibili con un clic che reindirizzano i pesi di Front Door/Traffic Manager, annullano gli slot swap o ridistribuiscono l’ultima build valida conosciuta (last known good). Mantenere l’artefatto precedente prontamente disponibile e documentare il processo decisionale.
Il rollback del database richiede particolare attenzione. Evitare modifiche non retrocompatibili. Utilizzare il pattern expand-contract: aggiungere colonne/tabelle e popolarle mantenendo la compatibilità in lettura/scrittura; se necessario, distribuire codice che scrive su entrambi gli schemi; solo in seguito rimuovere gli elementi deprecati. Per Azure SQL Database, combinare:
- DACPAC o framework di migrazione (EF Core) con script idempotenti e versionati e validazione pre/post-deployment.
- Operazioni online (ricostruzione di indici con opzione resumable, partition switching) per minimizzare la contenzione sui lock.
- Point-in-time restore e geo-replica attiva come ultima risorsa, riconoscendo il rischio di perdita di dati. Disattivare le funzionalità tramite flag prima di qualsiasi downgrade dello schema. Controllare le promozioni tramite gate basati sull’integrità del database (DTU/CPU, deadlock) acquisiti in Azure Monitor e Query Store.

Feature Flag con Azure App Configuration e Automazione delle Note di Rilascio

Azure App Configuration centralizza la gestione delle funzionalità con SDK per .NET, Java, Node.js e altri. Utilizza le etichette (label) per definire l’ambito dei flag per ambiente o anello di distribuzione (ring) e abilita l’aggiornamento dinamico in modo che le app acquisiscano le modifiche senza un nuovo deploy.

I filtri di targeting consentono un’abilitazione granulare basata su utente/gruppo, claim, dispositivo o attributi personalizzati. Definisci coorti (ad es. tenant interni, clienti VIP) da allineare con gli anelli di distribuzione.
Il rollout percentuale espone gradualmente le funzionalità a un sottoinsieme casuale di utenti. Inizia con l'1–5%, valida i KPI e poi aumenta. Coordina con la ponderazione di Front Door per un controllo a più livelli a livello di utente e di traffico.
I kill switch disattivano istantaneamente una funzionalità in caso di incidenti. Proteggi i percorsi ad alto rischio (pagamenti, scritture di dati) con un interruttore di disattivazione globale che non richiede alcun deploy per essere eseguito. Registra tutte le attivazioni/disattivazioni dei flag per l’audit e correlale con gli incidenti.

Automatizza le note di rilascio per fornire tracciabilità e comunicazione:

Imponi il collegamento degli elementi di lavoro (work item) richiedendo che i messaggi di commit e le PR facciano riferimento a degli ID. Azure DevOps associa automaticamente build e release a elementi di lavoro e commit.
Genera i changelog nelle pipeline utilizzando il task ‘Generate Release Notes’ o chiamate all’API REST per elencare le modifiche e gli elementi di lavoro dall’ultima distribuzione riuscita nell’ambiente di destinazione. Produci un output in Markdown con sezioni per funzionalità, correzioni, breaking change e migrazioni del database.
Pubblica le note sul Wiki del progetto, impacchettale come artefatto di build e allegale alla release. Includi i metadati della distribuzione (numero di build, SHA del commit, ambiente, approvatori, gate superati) per la conformità.

Scenario Pratico

Adobe deve introdurre un nuovo motore di personalizzazione nei suoi siti di marketing ospitati su Azure senza rischiare di compromettere i tassi di conversione durante le campagne di punta. Il team deve effettuare deploy frequenti, esporre progressivamente la funzionalità, validare gli SLO e poter effettuare un rollback istantaneo se i KPI si degradano.

Definire gli ambienti con Azure Deployment Environments

Crea definizioni di ambiente (Bicep) per app, AKS, Azure SQL e Front Door in un catalogo basato su Git. Gli sviluppatori possono effettuare il provisioning autonomo di ambienti di dev/test in sicurezza, garantendo la parità con la produzione e abilitando stack di test effimeri per gli esperimenti. ADE applica quote e RBAC per controllare la spesa e gli accessi.

Creare un unico build, distribuire più volte con YAML multi-stage

Un singolo artefatto viene promosso attraverso gli stage ring-r0, ring-r1, ring-r2 e prod. Gli stage dipendono l’uno dall’altro e utilizzano job di distribuzione con strategie canary e rolling dove appropriato, garantendo binari coerenti tra i vari anelli.

Utilizzare la strategia blue-green con gli slot di App Service per il livello web legacy

Esegui il deploy su uno slot di staging, effettua il warm-up e poi scambia (swap) per gli utenti interni dell’anello ring-r0. Se gli SLO di Adobe regrediscono, un nuovo scambio di slot (slot swap back) fornisce il rollback più rapido con un downtime quasi nullo.

Introdurre una strategia canary tramite il routing ponderato di Azure Front Door

Registra sia il backend di personalizzazione legacy che quello nuovo. Inizia con l'1% del traffico verso il nuovo backend nell’anello ring-r1. I probe di integrità (health probe) di Front Door e gli aggiornamenti istantanei della ponderazione consentono aggiustamenti sicuri e rapidi, allineati ai pattern di traffico.

Controllare le promozioni tra stage con gate e verifiche oggettive

Aggiungi controlli di Azure Monitor per la latenza p95, il tasso di errore e i KPI di conversione provenienti da Application Insights. Aggiungi una verifica tramite API REST al servizio di sperimentazione interno di Adobe per confermare le metriche di controllo (guardrail). Configura una verifica basata su una query di elementi di lavoro per assicurarsi che i bug ‘Must Fix’ siano chiusi prima di avanzare all’anello successivo. I gate vengono valutati periodicamente e hanno un timeout per prevenire che le modifiche rimangano bloccate.

Richiedere approvazioni nelle transizioni critiche

Le approvazioni pre-distribuzione per ring-r2 e prod richiedono il benestare del marketing e degli SRE, con un timeout di 4 ore per evitare release in sospeso. Le approvazioni post-distribuzione confermano che l’UAT e la validazione degli analytics sono completi prima di chiudere la release.

Controllare l’esposizione con i feature flag di Azure App Configuration

Implementa il dark launching in modo che il nuovo motore sia presente ma inizialmente disabilitato. Usa i filtri di targeting per abilitarlo per lo staff interno (ring-r0) e per coorti di clienti selezionate (ring-r1). Applica il rollout percentuale per espandere l’esposizione. Un kill switch disabilita il motore a livello globale in pochi secondi senza un nuovo deploy se compaiono anomalie.

Proteggere i dati con migrazioni di tipo expand-contract

Esegui prima il deploy delle modifiche SQL additive, popola i dati in modo asincrono (backfill) ed effettua una doppia scrittura (dual-write) dove necessario. Solo dopo aver provato la stabilità, rimuovi lo schema deprecato. I gate monitorano DTU, deadlock e query a lunga esecuzione per prevenire una promozione non sicura.

Automatizzare i percorsi di rollback

Gli hook di fallimento (failure hook) sui job di distribuzione attivano il rollback: le ponderazioni di Front Door tornano a 0% per il nuovo backend; App Service esegue uno scambio di slot inverso; AKS esegue kubectl rollout undo. Un rollback manuale con un solo clic rimane disponibile per gli operatori in scenari complessi.

Automatizzare la documentazione di rilascio

La pipeline genera note di rilascio in formato Markdown a partire dagli elementi di lavoro e dai commit associati, evidenziando le funzionalità attivate tramite flag, le modifiche al database e i gate superati. Le note vengono pubblicate sul Wiki di Azure DevOps e allegate alla release, soddisfacendo i requisiti di audit e di visibilità per gli stakeholder.

Questo approccio sfrutta ogni strumento per il suo punto di forza: ADE per ambienti sicuri e riproducibili; strategie YAML e approvazioni per un flusso governato; Front Door e App Configuration per una delivery progressiva a più livelli; Azure Monitor e i gate per un controllo di qualità oggettivo; e rollback e note di rilascio automatizzati per resilienza e tracciabilità.

← Containerizzazione e Kubernetes · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →