Il rilascio è il punto in cui il rischio si materializza. Il Well-Architected Framework è esplicito: non esistono deployment a basso rischio in produzione, e la raccomandazione OE:11 chiede pratiche di rilascio sicuro che coprano sia i rilasci di routine sia quelli di emergenza. Su AZ-400 la domanda non è “come si configura uno swap”, ma “dato questo vincolo di continuità di servizio, quale meccanismo lo soddisfa e quale prezzo pago”. Diamo per acquisiti i meccanismi di base e concentriamoci sulle decisioni di design.

Dove agisce davvero la leva sul downtime

Le tecniche per azzerare la finestra di indisponibilità non sono intercambiabili: differiscono per granularità del rollback, costo infrastrutturale e superficie di configurazione che portano con sé.

Slot swap in App Service. Lo swap non copia file: scambia le regole di routing dopo aver riscaldato le istanze dello slot sorgente. Il target (produzione) resta online per tutta la preparazione e nessuna richiesta viene persa. Richiede il tier Standard, Premium o Isolated. Due implicazioni di design pesano nelle scelte d’esame. Primo: alcune impostazioni sono slot-specific e non seguono il contenuto — tra cui domini custom, restrizioni IP, identità gestite, integrazione VNet, impostazioni di diagnostica — mentre app settings e connection string vengono scambiate a meno che non le marchi esplicitamente come slot setting. Se il requisito è “la connection string di produzione non deve mai finire nello slot di staging”, la risposta è quel flag, non una pipeline che riscrive la configurazione. Secondo: le istanze pre-swap vengono riciclate nell’ultimo passo dello swap, quindi le operazioni long-running in corso vengono abbandonate. Nessuna configurazione di rilascio compensa un worker che perde il lavoro a metà: il codice deve essere fault tolerant.

Swap with preview è la variante da scegliere quando la validazione deve avvenire con le impostazioni di produzione già applicate: la prima fase le applica allo slot sorgente e mette in pausa, permettendoti di collaudare prima di completare. Non è utilizzabile se l’autenticazione del sito è abilitata su uno degli slot. Auto swap elimina la validazione manuale, ma non è supportato su App Service su Linux né su Web App for Containers: se lo scenario è un container, il percorso è deploy sullo slot e swap esplicito dalla pipeline.

Traffic split e rolling. Quando il requisito è esporre progressivamente e non ribaltare in un istante, il routing percentuale sugli slot instrada una quota casuale di client, che restano pinnati per un’ora tramite il cookie x-ms-routing-name. In Container Apps la stessa esigenza si risolve con la multiple revision mode: revision immutabili, traffico ripartito in percentuale, e le label che espongono un URL stabile verso una singola revision, indipendente dallo split. In single revision mode il servizio garantisce già zero downtime, ma perdi il controllo sull’esposizione progressiva. Su macchine virtuali la leva è la strategia rolling dei deployment job di Azure Pipelines, con maxParallel espresso come numero o percentuale di target per iterazione: attenzione, la strategia rolling è supportata solo per risorse di tipo VM. Per Kubernetes la strategia corrispondente è canary, con increments e i lifecycle hook routeTraffic e postRouteTraffic che ospitano lo spostamento del traffico e il monitoraggio della salute.

La regola trasversale: il bake time fra un’onda e la successiva va misurato in ore e giorni, non in minuti, e va aumentato a ogni gruppo per coprire fusi orari e pattern d’uso diversi. Un canary che promuove dopo cinque minuti non è progressive exposure.

Ordinare deployment dipendenti in modo affidabile

Quando due componenti hanno un vincolo di precedenza — schema prima dell’applicazione, servizio a valle prima del chiamante — il rischio non è solo l’ordine sbagliato, ma le esecuzioni sovrapposte.

L’ordine intra-pipeline si esprime con la dipendenza fra stage; il problema difficile è la concorrenza fra run diverse. In Azure Pipelines il controllo è l’exclusive lock sulla risorsa, combinato con lockBehavior: runLatest (default) fa acquisire il lock solo alla run più recente e scarta le intermedie, sequential lo fa acquisire a tutte le run in ordine. La scelta è sostanziale: se ogni deployment porta una migrazione che non può essere saltata, ti serve sequential; se il deployment è idempotente e conta solo lo stato finale, runLatest riduce il tempo di coda. In GitHub Actions il costrutto equivalente è il concurrency group, dove cancel-in-progress annulla la run in corso.

L’ordine, però, non basta. Le modifiche a database, schema e altri componenti stateful sono le più difficili da annullare: la conseguenza di design è progettarle retrocompatibili, così che la versione precedente dell’applicazione continui a funzionare sul nuovo schema. È questo che rende reversibile il deployment applicativo, non la pipeline.

Fra uno stage e il successivo, infine, il gate non deve essere solo un’approvazione umana. Il check Query Azure Monitor Alerts blocca l’avanzamento se sono attivi alert dopo la fase precedente: è la traduzione operativa dell’idea che ogni fase debba superare un health model prima che inizi la successiva.

Il percorso di hotfix: accelerare senza smontare i gate

Un hotfix ad alta priorità non è un rilascio “senza regole”: è un rilascio con un protocollo di emergenza definito in anticipo. Il WAF elenca le leve legittime, tra cui l’accelerazione delle fasi di promozione e approvazione, quella di smoke test e test di integrazione, e la riduzione del bake time. Il punto architetturale è il secondo requisito: definire chi può approvare l’accelerazione e con quali criteri. Un percorso di hotfix che dipende da chi è reperibile quella notte non è un design.

Sul piano degli strumenti, in Azure Pipelines il bypass di un check (approvazione, business hours, invoke function o REST API) è riservato a chi ha permessi di amministratore sulla risorsa e resta tracciato con l’identità di chi lo ha effettuato: la deroga è controllata e auditabile, non invisibile. In GitHub Actions il controllo simmetrico sugli environment è la possibilità di disabilitare il bypass degli amministratori sulle protection rule, così che nemmeno un hotfix possa saltare i reviewer richiesti: si configura però sul singolo environment, da chi ha accesso admin al repository, non con una policy centrale a livello di organizzazione. Le due configurazioni rispondono a filosofie opposte, ed è esattamente la scelta che un item d’esame ti chiede di motivare.

Sul versionamento la guida è netta: preferire un modello release flow o trunk-based a Gitflow o al branching per ambiente. Un hotfix nasce da un branch di breve vita sul tronco, passa dallo stesso pipeline di produzione con i gate accelerati e rientra immediatamente nel tronco. Il branch di hotfix che sopravvive settimane è il modo più comune per far ricomparire il difetto al rilascio successivo.

Resilienza al deployment fallito

Alla rilevazione di un problema, il rollout si ferma subito: prima si arresta, poi si indaga. Le opzioni di recupero sono tre, e non sono equivalenti.

  • Rollback: tornare all’ultima configurazione funzionante. Su App Service è banale — si esegue lo stesso swap una seconda volta e lo slot che ora contiene la versione precedente torna in produzione. In Container Apps si riporta il traffico su una revision precedente, sfruttando lo storico di revision inattive conservate.
  • Roll forward: correggere in corsa applicando un hotfix. Scelta obbligata quando il rollback è impraticabile, tipicamente per una modifica stateful già propagata. Va gestita con la stessa disciplina, non come scorciatoia.
  • Deploy di nuova infrastruttura dall’ultima configurazione valida. È l’opzione che il pattern Deployment Stamps rende naturale, e che presuppone infrastruttura come codice e artefatti versionati.

Tre precondizioni rendono queste opzioni realmente disponibili: versionare gli artefatti, usare i feature flag per disattivare una funzionalità senza ridistribuire, e conoscere le capacità di point-in-time restore del data store per la parte non annullabile dal pipeline. I lifecycle hook on: failure dei deployment job esistono proprio per ospitare queste azioni compensative.

Come cade all’esame

Le domande su questo dominio raramente chiedono la sintassi: chiedono di abbinare un vincolo al meccanismo minimo che lo soddisfa. Aspettati scenari in cui devi scegliere fra swap, swap with preview e auto swap sapendo che il carico gira su container Linux, oppure decidere fra sequential e runLatest sapendo che ogni run porta una migrazione. Ricorrono la distinzione fra impostazioni scambiate e slot-specific, il limite della strategia rolling alle sole risorse VM, e il rollback via secondo swap come alternativa a un ridispiegamento completo.

Sul fronte hotfix, le domande ruotano attorno a chi può derogare e a come la deroga viene registrata: il bypass amministrativo dei check in Azure Pipelines e la disabilitazione del bypass sugli environment GitHub sono le due facce da riconoscere. Sulla resilienza, distingui sempre rollback, roll forward e nuova infrastruttura. Quando due opzioni sembrano entrambe corrette, scegli quella che riduce il blast radius ed espone il cambiamento progressivamente con un bake time adeguato: è il criterio che il Well-Architected Framework applica in modo coerente.