Cloud | The .NET Blog

Aggiornamenti di Azure Developer CLI (azd) per aprile 2026

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Azure Developer CLI (azd) ha rilasciato cinque versioni ad aprile 2026 (dalla 1.23.14 alla 1.24.2), con il grande tema degli hook che ora si eseguono in Python, JavaScript, TypeScript e .NET — non solo in Bash e PowerShell.

Hook multi-linguaggio in azure.yaml

Gli hook possono ora puntare a file .py, .js, .ts o .cs oltre agli script shell. Ogni linguaggio ottiene la risoluzione automatica delle dipendenze:

Python — rileva requirements.txt o pyproject.toml, crea un virtualenv e installa le dipendenze prima dell’esecuzione. Configura il nome dell’ambiente con virtualEnvName.
JavaScript / TypeScript — rileva package.json ed esegue npm install automaticamente. TypeScript viene eseguito tramite npx tsx senza necessità di un passaggio di compilazione. Scegli il tuo package manager con il blocco di configurazione packageManager.
.NET — esegue file .cs con dotnet run. Gli script single-file sono supportati su .NET 10+. Configura il framework di destinazione tramite il blocco configuration/framework.

Questo significa che i team che già lavorano in uno di questi linguaggi non hanno più bisogno di mantenere un hook Bash o PowerShell separato solo per collegare gli eventi del ciclo di vita del provisioning.

azd update arriva in preview pubblica

azd update è ora in preview pubblica su tutte le piattaforme. Un singolo comando gestisce l’aggiornamento indipendentemente da come azd è stato installato originalmente — non è più necessario tracciare separatamente i percorsi di Homebrew, WinGet o MSI.

Modalità non interattiva tramite AZD_NON_INTERACTIVE

Impostare AZD_NON_INTERACTIVE=true (o usare --non-interactive / --no-prompt) produce ora fallimenti coerenti e deterministici nelle pipeline CI/CD quando un input richiesto non può essere risolto automaticamente. In precedenza il comportamento era inconsistente tra i comandi.

Verifica preliminare della quota dei modelli AI

azd provision valida la quota di Azure Cognitive Services prima di tentare di effettuare il provisioning delle risorse dei modelli AI. I deployment che fallirebbero a causa dei limiti di quota ora mostrano l’errore all’inizio del processo anziché a metà del provisioning.

“Correggi questo errore” nella risoluzione dei problemi di Copilot

L’integrazione per la risoluzione dei problemi di Copilot in azd ottiene la capacità di applicare direttamente una correzione suggerita — non solo di descriverla. Quando l’agente identifica un problema risolvibile, può apportare la modifica in loco.

Provider di provisioning personalizzati e resolver di segreti Key Vault

Gli autori di estensioni possono ora registrare backend di infrastruttura alternativi con WithProvisioningProvider(). Separatamente, azd risolve automaticamente i riferimenti @Microsoft.KeyVault(...) prima di passare la configurazione alle estensioni, eliminando la necessità di una risoluzione manuale dei segreti nei provider personalizzati.

Esclusioni per template e modalità watch

Due nuovi file ignore offrono un controllo più preciso sulla gestione dei file:

.azdignore — esclude i file riservati ai contributori (documentazione, configurazioni CI) dalle copie dei template affinché gli utenti finali ottengano uno scaffold di progetto pulito.
.azdxignore — esclude le directory dal trigger di ricostruzioni durante azd x watch, riducendo il rumore durante lo sviluppo iterativo.

Verifica preliminare dei nomi riservati e opzione docker.network

azd avverte ora quando i nomi di risorse previsti conterrebbero parole riservate di Azure (MICROSOFT, WINDOWS o il prefisso LOGIN) prima che inizi il provisioning. Una nuova opzione docker.network passa --network a docker build, utile negli ambienti proxy aziendali che richiedono una rete Docker specifica.

Correzioni di sicurezza

Il pacchetto MSI di Windows ora include la verifica della firma del codice. Una correzione separata chiude una perdita di variabili d’ambiente che poteva esporre valori attraverso i confini dei comandi delle estensioni.

Un mese intenso — il supporto degli hook multi-linguaggio in particolare elimina un vero punto di attrito per i team che non lavorano principalmente in Bash. Consulta le note di rilascio complete per il changelog completo di tutte e cinque le versioni.

I tuoi esperimenti IA su Azure stanno bruciando soldi — Ecco come risolvere

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se stai costruendo app basate sull’IA su Azure in questo momento, probabilmente hai notato qualcosa: la tua bolletta cloud è diversa rispetto a prima. Non solo più alta — più strana. A picchi. Difficile da prevedere.

Microsoft ha appena pubblicato un ottimo articolo sui principi di ottimizzazione dei costi cloud che contano ancora, e onestamente, il tempismo non potrebbe essere migliore. Perché i carichi di lavoro IA hanno cambiato le regole del gioco per quanto riguarda i costi.

Perché i carichi di lavoro IA colpiscono diversamente

Ecco il punto. I carichi di lavoro .NET tradizionali sono relativamente prevedibili. Conosci il tuo tier App Service, conosci i tuoi DTU SQL, puoi stimare la spesa mensile abbastanza precisamente. Carichi di lavoro IA? Non proprio.

Stai testando più modelli per vedere quale si adatta. Stai avviando infrastruttura con GPU per il fine-tuning. Stai facendo chiamate API ad Azure OpenAI dove il consumo di token varia enormemente in base alla lunghezza del prompt e al comportamento degli utenti. Ogni esperimento costa soldi veri, e potresti farne decine prima di trovare l’approccio giusto.

Questa imprevedibilità è ciò che rende l’ottimizzazione dei costi critica — non come un ripensamento, ma dal primo giorno.

Gestione vs. ottimizzazione — conosci la differenza

Una distinzione dell’articolo che secondo me gli sviluppatori trascurano: c’è una differenza tra gestione dei costi e ottimizzazione dei costi.

La gestione è tracciamento e reporting. Imposti budget in Azure Cost Management, ricevi avvisi, vedi dashboard. Questo è il minimo indispensabile.

L’ottimizzazione è dove prendi effettivamente le decisioni. Hai davvero bisogno di quel tier S3, o l’S1 gestirebbe il tuo carico? Quell’istanza di compute sempre attiva sta ferma nei weekend? Potresti usare istanze spot per i tuoi job di addestramento?

Come sviluppatori .NET, tendiamo a concentrarci sul codice e lasciare le decisioni sull’infrastruttura al “team ops”. Ma se stai facendo deploy su Azure, quelle decisioni sono anche le tue.

Cosa funziona davvero

Basandomi sull’articolo e sulla mia esperienza personale, ecco cosa fa la differenza:

Sappi cosa stai spendendo e dove. Tagga le tue risorse. Sul serio. Se non riesci a capire quale progetto o esperimento sta mangiando il tuo budget, non puoi ottimizzare nulla. Azure Cost Management con un tagging appropriato è il tuo migliore amico.

Metti dei guardrail prima di sperimentare. Usa Azure Policy per limitare SKU costosi negli ambienti dev/test. Imposta limiti di spesa sui tuoi deployment Azure OpenAI. Non aspettare che arrivi la bolletta per scoprire che qualcuno ha lasciato un cluster GPU acceso tutto il weekend.

Ridimensiona continuamente. Quella VM che hai scelto durante il prototipo? Probabilmente è sbagliata per la produzione. Azure Advisor ti dà raccomandazioni — guardale davvero. Rivedi mensilmente, non annualmente.

Pensa al ciclo di vita. Le risorse di sviluppo dovrebbero spegnersi. Gli ambienti di test non devono girare 24/7. Usa policy di spegnimento automatico. Per i carichi di lavoro IA nello specifico, considera opzioni serverless dove paghi per esecuzione invece di mantenere il compute attivo.

Misura il valore, non solo il costo. Questa è facile da dimenticare. Un modello che costa di più ma fornisce risultati significativamente migliori potrebbe essere la scelta giusta. L’obiettivo non è spendere il meno possibile — è spendere in modo intelligente.

Il punto chiave

L’ottimizzazione dei costi cloud non è una pulizia una tantum. È un’abitudine. E con i carichi di lavoro IA che rendono la spesa meno prevedibile che mai, costruire questa abitudine presto ti risparmia sorprese dolorose in futuro.

Se sei uno sviluppatore .NET che costruisce su Azure, inizia a trattare la tua bolletta cloud come tratti il tuo codice — rivedila regolarmente, fai refactoring quando diventa disordinata, e non fare mai deploy senza capire quanto ti costerà.