Devops | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 acontece de 11 a 15 de maio de 2026 no Barbican Centre em Londres. A conferência principal de 3 dias vai de terça a quinta, com workshops opcionais de dia inteiro na segunda e na sexta.

Com 78 sessões e 14 workshops, é uma das conferências mais completas para desenvolvedores na Europa.

Tópicos

Pensamento Arquitetural
Código Funcional em C# 13
Design Serverless
IA Semântica
Azure Kubernetes Services
Estratégias Lean DevOps
The Model Context Protocol (MCP)
IA Agêntica em .NET
Refatorando o Monolito
Programar Mais Rápido com LLMs
Criptografia em um Mundo Pós-Quântico
Desenvolvimento Local First

Palestrantes

Elenco de classe mundial incluindo Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm e Raju Gandhi.

Ingressos e informações

98% dos participantes do SDD 2025 avaliaram a experiência geral como boa, muito boa ou excelente.

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.

Azure DevOps Server Patch Abril 2026 — Correção na Conclusão de PRs e Atualizações de Segurança

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Aviso rápido para equipes que rodam Azure DevOps Server auto-hospedado: a Microsoft lançou o Patch 3 de abril 2026 com três correções direcionadas.

O que foi corrigido

Falhas na conclusão de pull requests — uma exceção de referência nula durante o auto-completamento de work items podia causar falhas nos merges de PRs. Se você encontrou erros aleatórios na conclusão de PRs, essa é provavelmente a causa
Validação de redirecionamento no logout — validação aprimorada durante o logout para prevenir possíveis redirecionamentos maliciosos. Essa é uma correção de segurança que vale a pena aplicar logo
Conexões PAT com GitHub Enterprise Server — a criação de conexões por Personal Access Token com o GitHub Enterprise Server estava quebrada, agora foi restaurada

Como atualizar

Baixe o Patch 3 e execute o instalador. Para verificar se o patch foi aplicado:

<patch-installer>.exe CheckInstall

Se você roda Azure DevOps Server on-premises, a Microsoft recomenda fortemente manter-se no patch mais recente tanto por segurança quanto por confiabilidade. Confira as notas de versão para todos os detalhes.

A Engenharia de Plataformas Agêntica Está se Tornando Real — Git-APE Mostra Como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Engenharia de plataformas tem sido um daqueles termos que soam ótimos em conferências, mas que normalmente significam “construímos um portal interno e um wrapper de Terraform.” A verdadeira promessa — infraestrutura self-service que seja realmente segura, governada e rápida — sempre esteve a alguns passos de distância.

O time Azure acaba de publicar a Parte 2 da série sobre engenharia de plataformas agêntica, e esta é toda sobre a implementação prática. Eles chamam de Git-APE (sim, a sigla é intencional), e é um projeto open source que usa agentes do GitHub Copilot mais servidores Azure MCP para transformar solicitações em linguagem natural em infraestrutura validada e implantada.

O que o Git-APE realmente faz

A ideia central: em vez de desenvolvedores aprenderem módulos Terraform, navegarem por UIs de portais ou abrirem tickets para o time de plataforma, eles conversam com um agente Copilot. O agente interpreta a intenção, gera Infrastructure-as-Code, valida contra políticas e implanta — tudo dentro do VS Code.

Aqui está a configuração:

git clone https://github.com/Azure/git-ape
cd git-ape

Abra o workspace no VS Code, e os arquivos de configuração do agente são descobertos automaticamente pelo GitHub Copilot. Você interage diretamente com o agente:

@git-ape deploy a function app with storage in West Europe

O agente usa o Azure MCP Server por baixo dos panos para interagir com os serviços Azure. A configuração MCP nas opções do VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por que isso importa

Para nós que construímos no Azure, isso muda a conversa de engenharia de plataformas de “como construímos um portal” para “como descrevemos nossas guardrails como APIs.” Quando a interface da sua plataforma é um agente de IA, a qualidade das suas restrições e políticas se torna o produto.

O blog da Parte 1 apresentou a teoria: APIs bem descritas, schemas de controle e guardrails explícitas tornam as plataformas agent-ready. A Parte 2 prova que funciona entregando ferramentas reais. O agente não gera recursos cegamente — valida contra melhores práticas, respeita convenções de nomenclatura e aplica as políticas da sua organização.

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

Vou ser honesto — aqui é mais sobre o padrão do que sobre a ferramenta específica. O Git-APE em si é uma demo/arquitetura de referência. Mas a ideia subjacente — agentes como a interface da sua plataforma, MCP como protocolo, GitHub Copilot como host — é para onde a experiência do desenvolvedor enterprise está caminhando.

Se você é um time de plataforma procurando como tornar seu ferramental interno amigável para agentes, não há melhor ponto de partida. E se você é um desenvolvedor .NET se perguntando como isso se conecta ao seu mundo: o Azure MCP Server e os agentes do GitHub Copilot funcionam com qualquer workload Azure. Sua API ASP.NET Core, seu stack .NET Aspire, seus microsserviços em containers — tudo pode ser alvo de um fluxo de deploy agêntico.

Concluindo

Git-APE é um olhar inicial mas concreto sobre engenharia de plataformas agêntica na prática. Clone o repo, experimente a demo e comece a pensar em como as APIs e políticas da sua plataforma precisariam ser para que um agente as use com segurança.

Leia o post completo para o walkthrough e vídeos de demonstração.

Azure DevOps finalmente corrige o editor Markdown que todo mundo reclamava

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Se você usa Azure Boards, provavelmente já passou por isso: está lendo a descrição de um work item, talvez revisando critérios de aceitação, e acidentalmente dá um duplo clique. Boom — está em modo de edição. Não queria editar nada. Estava apenas lendo.

Dan Hellem anunciou a correção, e é uma daquelas mudanças que parecem pequenas mas realmente removem fricção do seu fluxo de trabalho diário.

O que mudou

O editor Markdown para campos de texto de work items agora abre em modo de visualização por padrão. Você pode ler e interagir com o conteúdo — seguir links, revisar formatação — sem se preocupar em entrar acidentalmente no modo de edição.

Quando realmente quer editar, clica no ícone de edição no topo do campo. Quando termina, sai explicitamente para o modo de visualização. Simples, intencional, previsível.

Por que isso importa mais do que parece

O thread de feedback da comunidade era longo. O comportamento de duplo clique para editar foi introduzido com o editor Markdown em julho de 2025, e as reclamações começaram quase imediatamente.

Para times que fazem planejamento de sprint, refinamento de backlog ou revisão de código com Azure Boards, esse tipo de micro-fricção se acumula.

Status da implantação

Já está sendo implementado para um subconjunto de clientes e se expandirá para todos nas próximas duas a três semanas.

Conclusão

Nem toda melhoria precisa ser uma funcionalidade de destaque. Às vezes a melhor atualização é simplesmente remover algo irritante. Esta é uma dessas — uma pequena correção de UX que torna o Azure Boards menos hostil para pessoas que só querem ler seus work items em paz.

Azure DevOps MCP Server chega ao Microsoft Foundry: O que isso significa para seus agentes de IA

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) está tendo seu momento. Se você tem acompanhado o ecossistema de agentes de IA, provavelmente notou servidores MCP surgindo por todo lado — dando aos agentes a capacidade de interagir com ferramentas e serviços externos através de um protocolo padronizado.

Agora o Azure DevOps MCP Server está disponível no Microsoft Foundry, e essa é uma daquelas integrações que faz você pensar nas possibilidades práticas.

O que está realmente acontecendo aqui

A Microsoft já lançou o Azure DevOps MCP Server como public preview — esse é o servidor MCP em si. A novidade é a integração com o Foundry. Agora você pode adicionar o Azure DevOps MCP Server aos seus agentes Foundry diretamente do catálogo de ferramentas.

Para quem ainda não conhece o Foundry: é a plataforma unificada da Microsoft para construir e gerenciar aplicações e agentes alimentados por IA em escala. Acesso a modelos, orquestração, avaliação, deploy — tudo em um só lugar.

Configurando

A configuração é surpreendentemente simples:

No seu agente Foundry, vá para Add Tools > Catalog
Busque “Azure DevOps”
Selecione o Azure DevOps MCP Server (preview) e clique em Create
Insira o nome da sua organização e conecte

Isso é tudo. Seu agente agora tem acesso às ferramentas do Azure DevOps.

Controlando o que seu agente pode acessar

Essa é a parte que eu aprecio: você não está preso a uma abordagem de tudo-ou-nada. Você pode especificar quais ferramentas estão disponíveis para seu agente. Então se você quer que ele apenas leia work items mas não toque em pipelines, pode configurar isso. Princípio do menor privilégio, aplicado aos seus agentes de IA.

Isso importa para cenários enterprise onde você não quer que um agente acidentalmente dispare um pipeline de deploy porque alguém pediu para ele “ajudar com o release.”

Por que isso é interessante para equipes .NET

Pense no que isso possibilita na prática:

Assistentes de planejamento de sprint — agentes que podem buscar work items, analisar dados de velocidade e sugerir capacidade de sprint
Bots de code review — agentes que entendem o contexto do seu PR porque podem realmente ler seus repos e work items vinculados
Resposta a incidentes — agentes que podem criar work items, consultar deploys recentes e correlacionar bugs com mudanças recentes
Onboarding de desenvolvedores — “No que devo trabalhar?” recebe uma resposta real baseada em dados reais do projeto

Para equipes .NET que já usam Azure DevOps para seus pipelines de CI/CD e gerenciamento de projetos, ter um agente de IA que pode interagir diretamente com esses sistemas é um passo significativo em direção à automação útil.

O panorama maior do MCP

Isso faz parte de uma tendência mais ampla: servidores MCP estão se tornando a forma padrão como agentes de IA interagem com o mundo exterior. Estamos vendo para GitHub, Azure DevOps, bancos de dados, APIs SaaS — e o Foundry está se tornando o hub onde todas essas conexões se encontram.

Se você está construindo agentes no ecossistema .NET, vale a pena prestar atenção ao MCP. O protocolo é padronizado, as ferramentas estão amadurecendo, e a integração com Foundry torna acessível sem precisar configurar manualmente conexões de servidor.

Para finalizar

O Azure DevOps MCP Server no Foundry está em preview, então espere que ele evolua. Mas o workflow principal é sólido: conectar, configurar acesso às ferramentas e deixar seus agentes trabalharem com seus dados de DevOps. Se você já está no ecossistema Foundry, está a poucos cliques. Experimente e veja quais workflows você consegue construir.

Confira o anúncio completo para a configuração passo a passo e mais detalhes.