Cloud | The .NET Blog

Atualizações do Azure Developer CLI (azd) de abril de 2026

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

O Azure Developer CLI (azd) lançou cinco versões em abril de 2026 (1.23.14 a 1.24.2), com o grande tema sendo hooks que agora executam em Python, JavaScript, TypeScript e .NET — não apenas em Bash e PowerShell.

Hooks em múltiplos idiomas no azure.yaml

Os hooks agora podem apontar para arquivos .py, .js, .ts ou .cs além de scripts shell. Cada linguagem obtém resolução automática de dependências:

Python — detecta requirements.txt ou pyproject.toml, cria um virtualenv e instala dependências antes da execução. Configure o nome do ambiente com virtualEnvName.
JavaScript / TypeScript — detecta package.json e executa npm install automaticamente. TypeScript é executado via npx tsx sem etapa de compilação. Escolha seu gerenciador de pacotes com o bloco de configuração packageManager.
.NET — executa arquivos .cs com dotnet run. Scripts de arquivo único são suportados no .NET 10+. Configure o framework de destino através do bloco configuration/framework.

Isso significa que as equipes que já trabalham em uma dessas linguagens não precisam mais manter um hook Bash ou PowerShell separado apenas para conectar eventos do ciclo de vida de provisionamento.

azd update entra em pré-visualização pública

azd update está agora em pré-visualização pública em todas as plataformas. Um único comando gerencia a atualização independentemente de como o azd foi instalado originalmente — sem precisar rastrear separadamente caminhos de Homebrew, WinGet ou MSI.

Modo não interativo via AZD_NON_INTERACTIVE

Definir AZD_NON_INTERACTIVE=true (ou usar --non-interactive / --no-prompt) agora produz falhas consistentes e determinísticas em pipelines de CI/CD quando uma entrada necessária não pode ser resolvida automaticamente. Anteriormente, o comportamento era inconsistente entre os comandos.

Verificação prévia de cota de modelos de IA

azd provision valida a cota do Azure Cognitive Services antes de tentar provisionar recursos de modelos de IA. Implantações que falhariam por limites de cota agora exibem o erro cedo no processo em vez de no meio do provisionamento.

“Corrigir este erro” na solução de problemas do Copilot

A integração de solução de problemas do Copilot no azd ganha a capacidade de aplicar diretamente uma correção sugerida — não apenas descrevê-la. Quando o agente identifica um problema corrigível, ele pode fazer a alteração no local.

Provedores de provisionamento personalizados e resolvedor de segredos do Key Vault

Os autores de extensões agora podem registrar backends de infraestrutura alternativos com WithProvisioningProvider(). Separadamente, o azd resolve automaticamente referências @Microsoft.KeyVault(...) antes de passar a configuração para extensões, eliminando a necessidade de resolução manual de segredos em provedores personalizados.

Exclusões para templates e modo watch

Dois novos arquivos ignore oferecem controle mais preciso sobre o manuseio de arquivos:

.azdignore — exclui arquivos exclusivos para colaboradores (documentação, configurações de CI) de cópias de templates para que os usuários finais obtenham um scaffold de projeto limpo.
.azdxignore — exclui diretórios de disparar reconstruções durante azd x watch, reduzindo o ruído durante o desenvolvimento iterativo.

Preflight de nomes reservados e opção docker.network

O azd agora avisa quando os nomes de recursos previstos conteriam palavras reservadas do Azure (MICROSOFT, WINDOWS ou o prefixo LOGIN) antes do início do provisionamento. Uma nova opção docker.network passa --network para docker build, útil em ambientes de proxy corporativo que exigem uma rede Docker específica.

Correções de segurança

O pacote MSI do Windows agora inclui verificação de assinatura de código. Uma correção separada fecha um vazamento de variável de ambiente que poderia expor valores entre os limites dos comandos de extensão.

Um mês intenso — o suporte a hooks em múltiplas linguagens em particular elimina um ponto de fricção real para equipes que não trabalham principalmente em Bash. Consulte as notas de versão completas para o changelog completo de todas as cinco versões.

Seus experimentos de IA no Azure estão queimando dinheiro — Veja como resolver isso

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Se você está construindo apps com IA no Azure agora, provavelmente já notou algo: sua fatura da nuvem está diferente do que costumava ser. Não apenas mais alta — mais estranha. Com picos. Difícil de prever.

A Microsoft acabou de publicar um ótimo artigo sobre princípios de otimização de custos na nuvem que ainda importam, e honestamente, o timing não poderia ser melhor. Porque as cargas de trabalho de IA mudaram o jogo quando se trata de custos.

Por que cargas de trabalho de IA são diferentes

A questão é a seguinte. Cargas de trabalho tradicionais de .NET são relativamente previsíveis. Você conhece seu tier de App Service, conhece seus DTUs de SQL, consegue estimar o gasto mensal com bastante precisão. Cargas de trabalho de IA? Nem tanto.

Você está testando múltiplos modelos para ver qual se encaixa. Está subindo infraestrutura com GPU para fine-tuning. Está fazendo chamadas de API para o Azure OpenAI onde o consumo de tokens varia enormemente dependendo do tamanho do prompt e do comportamento do usuário. Cada experimento custa dinheiro real, e você pode executar dezenas antes de encontrar a abordagem certa.

Essa imprevisibilidade é o que torna a otimização de custos crítica — não como algo secundário, mas desde o primeiro dia.

Gerenciamento vs. otimização — saiba a diferença

Uma distinção do artigo que acho que os desenvolvedores ignoram: há uma diferença entre gerenciamento de custos e otimização de custos.

Gerenciamento é rastreamento e relatórios. Você configura orçamentos no Azure Cost Management, recebe alertas, vê dashboards. Isso é o básico.

Otimização é onde você realmente toma decisões. Você realmente precisa daquele tier S3, ou o S1 daria conta da sua carga? Aquela instância de compute sempre ligada está ociosa nos finais de semana? Você poderia usar instâncias spot para seus jobs de treinamento?

Como desenvolvedores .NET, tendemos a focar no código e deixar as decisões de infraestrutura para “o time de operações”. Mas se você está fazendo deploy no Azure, essas decisões também são suas.

O que realmente funciona

Com base no artigo e na minha própria experiência, é isso que faz a diferença:

Saiba o que está gastando e onde. Tagueie seus recursos. Sério. Se você não consegue identificar qual projeto ou experimento está consumindo seu orçamento, não consegue otimizar nada. Azure Cost Management com tagging adequado é seu melhor amigo.

Estabeleça limites antes de experimentar. Use Azure Policy para restringir SKUs caros em ambientes de dev/test. Defina limites de gasto nos seus deployments do Azure OpenAI. Não espere a fatura chegar para perceber que alguém deixou um cluster de GPU rodando no final de semana.

Redimensione continuamente. Aquela VM que você escolheu durante a prototipação? Provavelmente está errada para produção. O Azure Advisor dá recomendações — realmente olhe para elas. Revise mensalmente, não anualmente.

Pense no ciclo de vida. Recursos de desenvolvimento devem ser desligados. Ambientes de teste não precisam rodar 24/7. Use políticas de desligamento automático. Para cargas de trabalho de IA especificamente, considere opções serverless onde você paga por execução em vez de manter o compute ligado.

Meça o valor, não apenas o custo. Essa é fácil de esquecer. Um modelo que custa mais mas entrega resultados significativamente melhores pode ser a decisão certa. O objetivo não é gastar o mínimo — é gastar de forma inteligente.

A conclusão

Otimização de custos na nuvem não é uma limpeza pontual. É um hábito. E com cargas de trabalho de IA tornando os gastos menos previsíveis do que nunca, construir esse hábito cedo te poupa de surpresas dolorosas depois.

Se você é um desenvolvedor .NET construindo no Azure, comece a tratar sua fatura da nuvem como trata seu código — revise regularmente, refatore quando ficar bagunçado, e nunca faça deploy sem entender quanto vai custar.