Chi distribuisce applicazioni su Azure con Azure Developer CLI (azd) conosce bene il momento di tensione che precede un azd deploy: il comando scrive file di configurazione, aggiorna risorse e sincronizza il codice sui service target, ma fino a poco tempo fa non c’era modo di sapere in anticipo cosa sarebbe cambiato, se non eseguendo il deploy e osservando il risultato. Con la versione 1.35.0, rilasciata il 30 settembre 2026, il team di Azure SDK ha introdotto un meccanismo di anteprima del deployment, insieme al supporto per il nuovo modello Azure Container Apps Express. Due novità che, combinate, cambiano in modo concreto il flusso di lavoro di chi usa azd in pipeline CI/CD o in sviluppo locale.

Il nuovo flag --preview su azd deploy

La pull request #10055 ha introdotto nell’SDK di azd i contratti per estensioni che supportano anteprime di deployment in sola lettura, mentre la #10204 ha esposto questa capacità direttamente nel comando CLI con un nuovo flag:

azd deploy <service> --preview

Il comando azd deploy accetta oggi, tra gli altri, questi flag principali:

azd deploy [service] [flags]

--all                     Distribuisce tutti i servizi definiti in azure.yaml
--from-package string     Distribuisce da un pacchetto già creato (zip o tag immagine)
--preview                 Mostra un'anteprima delle modifiche senza distribuire
--timeout int             Timeout massimo per servizio in secondi (default 1200)
-e, --environment string  Ambiente azd da utilizzare

Il flag --preview è disponibile per gli host di servizio integrati: App Service, Azure Container Apps, Azure Functions, Static Web Apps, AKS ed endpoint AI. In pratica, prima di eseguire un deploy reale è possibile lanciare:

azd deploy web --preview
azd deploy --all --preview

e ottenere un report di ciò che il deployment andrebbe a modificare sull’infrastruttura di destinazione, senza alcun effetto collaterale sulle risorse Azure. Per chi lavora con azd in pipeline di CI/CD, questo apre la porta a un passaggio di validazione pre-merge: eseguire l’anteprima su una pull request e bloccare il merge se il diff proposto include cambiamenti inattesi (ad esempio una risorsa che verrebbe ricreata invece di aggiornata, con conseguente downtime). È lo stesso principio del terraform plan o del what-if di ARM/Bicep, finalmente disponibile anche nel livello applicativo gestito da azd.

Vale la pena notare che il meccanismo di anteprima nasce come contratto SDK aperto alle estensioni (PR #10055): significa che, oltre ai service target integrati, anche estensioni custom di azd potranno in futuro implementare la propria logica di anteprima, seguendo lo stesso pattern.

Container Apps Express: deploy immediato senza provisioning dell’environment

La seconda novità della 1.35.0 (PR #10223) è il supporto nativo al deployment su Azure Container Apps Express, la nuova modalità “leggera” di Container Apps pensata per API HTTP, frontend SaaS, gateway AI e backend di agenti, dove conta soprattutto la velocità con cui si passa da codice a URL pubblico.

La differenza rispetto al Container Apps “tradizionale” è sostanziale. Con Express, da riga di comando è ancora necessario creare l’environment, ma la piattaforma applica default opinionati che eliminano buona parte della configurazione di rete e scaling:

# Prerequisiti: estensione containerapp >= 1.3.0b4
az upgrade
az extension add -n containerapp
az extension update --name containerapp

# 1. Crea l'environment in modalità Express
az containerapp env create \
  --environment-mode express \
  --name my-express-env \
  --resource-group my-rg \
  --logs-destination none

# 2. Distribuisce il container (crea l'app se non esiste)
az containerapp up \
  --image docker.io/nginx \
  --name my-app \
  --resource-group my-rg

Al termine, la CLI restituisce l’URL pubblico dell’app, già raggiungibile. Con l’integrazione in azd, questo stesso flusso diventa parte del normale ciclo azd up / azd deploy, senza dover alternare tra az containerapp e azd per i progetti che puntano a un environment Express.

Express non è pensato per ogni scenario: le app girano solo su compute CPU a consumo (pay-as-you-go, scale-to-zero), supportano esclusivamente ingress HTTP (niente TCP, HTTP/2 o custom domain) e non includono sidecar, Dapr, job, identità gestita system-assigned, Key Vault secret reference o traffic splitting tra revisioni multiple. Lo storage effimero è limitato a 40 GiB per replica tramite volumi EmptyDir (massimo 10 per container), e il servizio è disponibile solo in un sottoinsieme di region Azure, tra cui Italy North, West Europe e East US. Per chi ha bisogno di GPU, service discovery tra microservizi o workload profile dedicati, resta necessario il modello Container Apps standard con Workload Profile environment.

Dove Express brilla è nei casi semplici: un’API REST, un piccolo backend per un agente AI, un frontend SaaS da validare rapidamente. In questi scenari l’assenza di provisioning complesso si traduce in un time-to-deploy misurabile in minuti, e il supporto nativo in azd significa poter definire questi servizi direttamente in azure.yaml insieme al resto dello stack applicativo.

Come usarli insieme in un workflow reale

Combinando le due feature, un flusso di lavoro tipico per un team che adotta azd 1.35.0 su un progetto Container Apps Express potrebbe essere:

# In una pull request: verifica cosa cambierebbe, senza toccare Azure
azd deploy api --preview

# Dopo l'approvazione, deploy effettivo
azd deploy api

# In caso di timeout su ambienti lenti o pipeline con molti servizi
azd deploy --all --timeout 1800

La 1.35.0 porta con sé anche due correzioni degne di nota per chi gestisce pipeline automatizzate: i timeout di deployment non vengono più mascherati come “passaggi saltati”, ma restano visibili insieme all’errore sottostante (PR #10157), e sono state risolte una race condition nel rendering della lista dei task e alcuni aggiornamenti incompleti della configurazione dell’ambiente (PR #10191) — entrambi bug che, in pipeline CI/CD ad alta concorrenza, potevano rendere difficile capire perché un deploy fosse effettivamente fallito.

Conclusione

Il flag --preview colma una lacuna che chiunque abbia gestito deployment di infrastruttura applicativa conosce bene: la differenza tra “sapere cosa sta per succedere” e “scoprirlo dopo che è successo”. Abbinato al supporto per Container Apps Express, azd 1.35.0 rende più sicuro il deploy automatizzato e più rapido il percorso dal codice al servizio in produzione per i casi d’uso più comuni — API HTTP e backend leggeri — senza rinunciare, per gli scenari più complessi, al modello Container Apps completo. Per i team che già usano azd in pipeline, vale la pena aggiornare e inserire --preview come step di validazione prima di ogni merge che tocchi l’infrastruttura.

Fonte: 4sysops – Azure Developer CLI adds deployment previews and Container Apps express support. Note di rilascio: GitHub – azure-dev-cli_1.35.0. Documentazione: Azure Container Apps Express overview.