Devops | The .NET Blog

SDD Conference 2026

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

SDD 2026 runs from May 11–15, 2026 at the Barbican Centre in London. The core 3-day conference is Tuesday through Thursday, with optional full-day workshops on Monday and Friday.

With 78 sessions and 14 workshops, this is one of the most packed developer conferences in Europe.

Topics

Architectural Thinking
Functional Code in C# 13
Serverless Design
Semantic AI
Azure Kubernetes Services
Lean DevOps Strategies
The Model Context Protocol (MCP)
Agentic AI in .NET
Refactoring the Monolith
Coding Faster with LLMs
Cryptography in a Post-Quantum World
Local First Development

Speakers

World-class lineup including Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm, and Raju Gandhi.

Tickets and info

98% of SDD 2025 attendees rated the overall experience as good, very good, or excellent.

Azure Developer CLI (azd) April 2026 Updates

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

Azure Developer CLI (azd) shipped five releases in April 2026 (1.23.14 through 1.24.2), with the big story being hooks that now run in Python, JavaScript, TypeScript, and .NET — not just Bash and PowerShell.

Multi-language hooks in azure.yaml

Hooks can now point to .py, .js, .ts, or .cs files in addition to shell scripts. Each language gets automatic dependency resolution:

Python — detects requirements.txt or pyproject.toml, creates a virtualenv, and installs deps before running. Configure the env name with virtualEnvName.
JavaScript / TypeScript — detects package.json and runs npm install automatically. TypeScript executes via npx tsx with no compile step needed. Choose your package manager with the packageManager config block.
.NET — runs .cs files with dotnet run. Single-file scripts are supported on .NET 10+. Configure the target framework via the configuration/framework block.

This means teams that already live in one of these languages no longer need to maintain a separate Bash or PowerShell hook just to wire up provisioning lifecycle events.

azd update graduates to public preview

azd update is now in public preview across all platforms. A single command handles the update regardless of how azd was originally installed — no more tracking down Homebrew, WinGet, or MSI paths separately.

Non-interactive mode via AZD_NON_INTERACTIVE

Setting AZD_NON_INTERACTIVE=true (or using --non-interactive / --no-prompt) now produces consistent, deterministic failures in CI/CD pipelines when a required input cannot be resolved automatically. Previously the behavior was inconsistent across commands.

AI model quota preflight check

azd provision validates Azure Cognitive Services quota before attempting to provision AI model resources. Deployments that would fail due to quota limits now surface the error early in the process rather than partway through provisioning.

“Fix this error” in Copilot troubleshooting

The azd Copilot troubleshooting integration gains the ability to directly apply a suggested fix — not just describe it. When the agent identifies a fixable issue, it can make the change in-place.

Custom provisioning providers and Key Vault secret resolver

Extension authors can now register alternative infrastructure backends with WithProvisioningProvider(). Separately, azd automatically resolves @Microsoft.KeyVault(...) references before passing configuration to extensions, removing the need for manual secret resolution in custom providers.

Template and watch-mode exclusions

Two new ignore files give finer control over file handling:

.azdignore — excludes contributor-only files (docs, CI configs) from template copies so end users get a clean project scaffold.
.azdxignore — excludes directories from triggering rebuilds during azd x watch, reducing noise during iterative development.

Reserved-name preflight and docker.network option

azd now warns when predicted resource names would contain Azure reserved words (MICROSOFT, WINDOWS, or the LOGIN prefix) before provisioning begins. A new docker.network option passes --network to docker build, which is useful in corporate proxy environments that require a specific Docker network.

Security fixes

The Windows MSI package now includes code-signing verification. A separate fix closes an environment variable leak that could expose values across extension command boundaries.

A packed month — the multi-language hook support in particular removes a real friction point for teams not working primarily in Bash. See the full release notes for the complete changelog across all five releases.

Azure DevOps Server April 2026 Patch — PR Completion Fix and Security Updates

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

Quick heads-up for teams running self-hosted Azure DevOps Server: Microsoft released Patch 3 for April 2026 with three targeted fixes.

What’s fixed

Pull request completion failures — a null reference exception during work item auto-completion could cause PR merges to fail. If you’ve hit random PR completion errors, this is likely the cause
Sign-out redirect validation — improved validation during sign-out to prevent potential malicious redirects. This is a security fix worth applying promptly
GitHub Enterprise Server PAT connections — creating Personal Access Token connections to GitHub Enterprise Server was broken, now it’s restored

How to update

Download Patch 3 and run the installer. To verify the patch is applied:

<patch-installer>.exe CheckInstall

If you’re running Azure DevOps Server on-premises, Microsoft strongly recommends staying on the latest patch for both security and reliability. Check the release notes for full details.

Agentic Platform Engineering Is Getting Real — Git-APE Shows How

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

Platform engineering has been one of those terms that sounds great in conference talks but usually means “we built an internal portal and a Terraform wrapper.” The real promise — self-service infrastructure that’s actually safe, governed, and fast — has always been a few steps away.

The Azure team just published Part 2 of their agentic platform engineering series, and this one is all about the hands-on implementation. They call it Git-APE (yes, the acronym is intentional), and it’s an open-source project that uses GitHub Copilot agents plus Azure MCP servers to turn natural-language requests into validated, deployed infrastructure.

What Git-APE actually does

The core idea: instead of developers learning Terraform modules, navigating portal UIs, or filing tickets to a platform team, they talk to a Copilot agent. The agent interprets the intent, generates Infrastructure-as-Code, validates it against policies, and deploys — all within VS Code.

Here’s the setup:

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

Open the workspace in VS Code, and the agent configuration files are auto-discovered by GitHub Copilot. You interact with the agent directly:

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

The agent uses Azure MCP Server under the hood to interact with Azure services. The MCP configuration in VS Code settings enables specific capabilities:

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

Why this matters

For those of us building on Azure, this shifts the platform engineering conversation from “how do we build a portal” to “how do we describe our guardrails as APIs.” When your platform’s interface is an AI agent, the quality of your constraints and policies becomes the product.

The Part 1 blog laid out the theory: well-described APIs, control schemas, and explicit guardrails make platforms agent-ready. Part 2 proves it works by shipping actual tooling. The agent doesn’t just blindly generate resources — it validates against best practices, respects naming conventions, and applies your organization’s policies.

Clean-up is just as easy:

@git-ape destroy my-resource-group

My take

I’ll be honest — this one is more about the pattern than the specific tool. Git-APE itself is a demo/reference architecture. But the underlying idea — agents as the interface to your platform, MCP as the protocol, GitHub Copilot as the host — is where enterprise developer experience is heading.

If you’re a platform team looking at how to make your internal tooling agent-friendly, there’s no better starting point. And if you’re a .NET developer wondering how this connects to your world: the Azure MCP Server and GitHub Copilot agents work with any Azure workload. Your ASP.NET Core API, your .NET Aspire stack, your containerized microservices — all of it can be the target of an agentic deployment flow.

Wrapping up

Git-APE is an early but concrete look at agentic platform engineering in practice. Clone the repo, try the demo, and start thinking about how your platform’s APIs and policies would need to look for an agent to safely use them.

Read the full post for the walkthrough and video demos.

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

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

If you use Azure Boards, you’ve probably experienced this: you’re reading through a work item description, maybe reviewing acceptance criteria, and you accidentally double-click. Boom — you’re in edit mode. You didn’t want to edit anything. You were just reading.

Dan Hellem announced the fix, and it’s one of those changes that sounds tiny but actually removes real friction from your daily workflow.

What changed

The Markdown editor for work item text fields now opens in preview mode by default. You can read and interact with the content — follow links, review formatting — without worrying about accidentally entering edit mode.

When you actually want to edit, you click the edit icon at the top of the field. When you’re done, you exit back to preview mode explicitly. Simple, intentional, predictable.

That’s it. That’s the change.

Why this matters more than it sounds

The community feedback thread on this was long. The double-click-to-edit behavior was introduced with the Markdown editor back in July 2025, and the complaints started almost immediately. The problem wasn’t just accidental edits — it was that the whole interaction felt unpredictable. You never knew if clicking would read or edit.

For teams that do sprint planning, backlog grooming, or code review with Azure Boards, this kind of micro-friction compounds. Every accidental edit mode entry is a context switch. Every “wait, did I change something?” moment is wasted attention.

The new default respects the most common interaction pattern: you read work items far more often than you edit them.

Rollout status

This is already rolling out to a subset of customers and expanding to everyone over the next two to three weeks. If you’re not seeing it yet, you will soon.

Wrapping up

Not every improvement needs to be a headline feature. Sometimes the best update is just removing something annoying. This is one of those — a small UX fix that makes Azure Boards feel less hostile to people who just want to read their work items in peace.

Azure DevOps MCP Server Lands in Microsoft Foundry: What This Means for Your AI Agents

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

MCP (Model Context Protocol) has been having a moment. If you’ve been following the AI agent ecosystem, you’ve probably noticed MCP servers popping up everywhere — giving agents the ability to interact with external tools and services through a standardized protocol.

Now the Azure DevOps MCP Server is available in Microsoft Foundry, and this is one of those integrations that makes you think about the practical possibilities.

What’s actually happening here

Microsoft already released the Azure DevOps MCP Server as a public preview — that’s the MCP server itself. What’s new is the Foundry integration. You can now add the Azure DevOps MCP Server to your Foundry agents directly from the tool catalog.

For those not familiar with Foundry yet: it’s Microsoft’s unified platform for building and managing AI-powered applications and agents at scale. Model access, orchestration, evaluation, deployment — all in one place.

Setting it up

The setup is surprisingly straightforward:

In your Foundry agent, go to Add Tools > Catalog
Search for “Azure DevOps”
Select the Azure DevOps MCP Server (preview) and click Create
Enter your organization name and connect

That’s it. Your agent now has access to Azure DevOps tools.

Controlling what your agent can access

Here’s the part I appreciate: you’re not stuck with an all-or-nothing approach. You can specify which tools are available to your agent. So if you only want it to read work items but not touch pipelines, you can configure that. Principle of least privilege, applied to your AI agents.

This matters for enterprise scenarios where you don’t want an agent accidentally triggering a deployment pipeline because someone asked it to “help with the release.”

Why this is interesting for .NET teams

Think about what this enables in practice:

Sprint planning assistants — agents that can pull work items, analyze velocity data, and suggest sprint capacity
Code review bots — agents that understand your PR context because they can actually read your repos and linked work items
Incident response — agents that can create work items, query recent deployments, and correlate bugs with recent changes
Developer onboarding — “What should I work on?” gets a real answer backed by actual project data

For .NET teams already using Azure DevOps for their CI/CD pipelines and project management, having an AI agent that can actually interact with those systems directly is a significant step toward useful automation (not just chatbot-as-a-service).

The bigger MCP picture

This is part of a broader trend: MCP servers are becoming the standard way AI agents interact with the outside world. We’re seeing them for GitHub, Azure DevOps, databases, SaaS APIs — and Foundry is becoming the hub where these connections all come together.

If you’re building agents in the .NET ecosystem, MCP is worth paying attention to. The protocol is standardized, the tooling is maturing, and the Foundry integration makes it accessible without having to manually wire up server connections.

Wrapping up

The Azure DevOps MCP Server in Foundry is in preview, so expect it to evolve. But the core workflow is solid: connect, configure tool access, and let your agents work with your DevOps data. If you’re already in the Foundry ecosystem, this is a few clicks away. Give it a try and see what workflows you can build.

Check out the full announcement for the step-by-step setup and more details.