Deployment slot: staging senza downtime

In Azure App Service (piani Standard, Premium e Isolated) puoi creare deployment slot: istanze parallele della stessa web app, ciascuna con il proprio hostname (es. myapp-staging.azurewebsites.net). Lo slot di default è production; gli altri servono per validare una build prima di portarla in produzione.

Il valore architetturale sta nello swap: invece di ridistribuire il codice sul production, promuovi lo slot di staging scambiando i due ambienti. Lo swap è un’operazione a livello di routing e non ricicla il worker, quindi elimina il downtime da avvio a freddo.

Swap with warm-up

Durante lo swap, App Service applica le impostazioni del target slot alle istanze del source slot e le riscalda prima di completare lo scambio: invia richieste alla root (o al path definito da WEBSITE_SWAP_WARMUP_PING_PATH / WEBSITE_WARMUP_PING_STATUSES) finché l’app non risponde. Questo garantisce che il primo utente in produzione non colpisca un processo appena avviato. Se qualcosa va storto puoi usare lo swap with preview (multi-fase) per applicare le impostazioni al source slot e verificare prima di confermare, oppure eseguire un rollback invertendo lo swap.

Slot settings (impostazioni sticky)

Ogni slot ha proprie app settings e connection string. Di default queste seguono lo swap insieme al contenuto. Se invece marchi un valore come slot setting (deployment slot setting), quel valore resta ancorato allo slot e non viene scambiato. Sono tipicamente slot setting:

  • Connection string verso database di staging vs produzione
  • Endpoint e chiavi di ambiente (es. istanze diverse di Application Insights)
  • Configurazioni di feature flag specifiche dell’ambiente

Regola chiave: se una impostazione deve cambiare a seconda dell’ambiente, marcala come slot setting su entrambi gli slot; altrimenti dopo lo swap lo staging erediterebbe i valori di produzione.

Opzioni di deploy

  • ZIP deploy (POST /api/zipdeploy o az webapp deploy): carichi uno zip che viene estratto in wwwroot. Innesca Oryx per il build remoto se SCM_DO_BUILD_DURING_DEPLOYMENT=true.
  • Run-from-package (WEBSITE_RUN_FROM_PACKAGE=1 o URL a un blob): il contenuto viene montato read-only direttamente dal package. Avvii più rapidi, deploy atomici, nessun file lock. Consigliato per Azure Functions e scenari immutabili.
  • Kudu / SCM: il sito di gestione (*.scm.azurewebsites.net) espone console, log stream, file system e le API di deploy. È il motore sottostante di molti metodi.
  • GitHub Actions / Azure Pipelines: CI/CD con azure/webapps-deploy, spesso con deploy sullo slot di staging seguito da swap automatico.
az webapp deploy --resource-group rg --name myapp \
  --slot staging --src-path ./app.zip --type zip

App settings vs appsettings.json

Le app settings definite sul portale/CLI/Bicep vengono iniettate come variabili d’ambiente nel processo. In un’app ASP.NET Core, il provider di configurazione legge le variabili d’ambiente con priorità più alta rispetto ad appsettings.json: una app setting Logging__LogLevel__Default sovrascrive il valore del file. Questo permette di tenere i default nel repo e i valori sensibili/ambientali fuori dal codice (idealmente riferendo Key Vault references).

Provisioning con Bicep

Slot e settings sono risorse ARM, quindi ripetibili via Bicep: Microsoft.Web/sites per l’app, sites/slots per lo slot, sites/config (o la proprietà siteConfig.appSettings) per le impostazioni. Marcare uno slot setting corrisponde ad aggiungerlo a Microsoft.Web/sites/config/slotConfigNames (appSettingNames / connectionStringNames).

Trappole tipiche d’esame

  • Serve staging + validazione prima della produzione, senza downtime → crea un deployment slot e usa lo swap with warm-up; non ridistribuire direttamente sul production slot.
  • Dopo lo swap l’app di produzione punta al DB di staging → la connection string non era marcata come slot setting: rendila slot setting su entrambi gli slot così resta ancorata.
  • Un valore in appsettings.json non ha effetto in Azure → una app setting con lo stesso nome lo sovrascrive come variabile d’ambiente (precedenza al runtime, ricorda __ per la gerarchia).
  • Deploy atomico, avvio veloce, file non modificabili a runtime (Functions) → usa run-from-package, non ZIP deploy con build remoto.
  • Lo slot non è disponibile / il menu Slots è disabilitato → il piano è Basic o Free: gli slot richiedono almeno Standard.