Devops | The .NET Blog

SDD Conference 2026

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

SDD 2026 于 2026年5月11日至15日 在 伦敦 Barbican Centre 举办。为期3天的核心大会从周二到周四，周一和周五有可选的全天工作坊。

拥有 78场演讲 和 14场工作坊，是欧洲内容最丰富的开发者大会之一。

主题

架构思维
C# 13 中的函数式代码
无服务器设计
语义 AI
Azure Kubernetes Services
精益 DevOps 策略
模型上下文协议 (MCP)
.NET 中的智能代理 AI
重构单体应用
使用 LLM 更快编程
后量子世界中的密码学
本地优先开发

演讲者

世界级阵容包括 Kevlin Henney、Neal Ford、Sander Hoogendoorn、Andrew Clymer、Jacqui Read、Christian Weyer、Jeff Prosise、Jules May、Oliver Sturm 和 Raju Gandhi。

门票和信息

98%的 SDD 2025 参会者将整体体验评为"好"、“非常好"或"优秀”。

Azure Developer CLI (azd) 2026年4月更新

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

本文已自动翻译。要查看原始版本，请点击此处.

Azure Developer CLI (azd) 在 2026 年 4 月发布了五个版本（1.23.14 至 1.24.2），重大主题是钩子现在可在 Python、JavaScript、TypeScript 和 .NET 中运行——而不仅限于 Bash 和 PowerShell。

azure.yaml 中的多语言钩子

除 shell 脚本外，钩子现在可以指向 .py、.js、.ts 或 .cs 文件。每种语言都可自动解析依赖关系：

Python — 检测 requirements.txt 或 pyproject.toml，创建 virtualenv 并在运行前安装依赖。通过 virtualEnvName 配置环境名称。
JavaScript / TypeScript — 检测 package.json 并自动运行 npm install。TypeScript 通过 npx tsx 执行，无需编译步骤。通过 packageManager 配置块选择包管理器。
.NET — 使用 dotnet run 运行 .cs 文件。在 .NET 10+ 上支持单文件脚本。通过 configuration/framework 块配置目标框架。

这意味着已在这些语言之一中工作的团队，不再需要仅为了连接预配生命周期事件而单独维护 Bash 或 PowerShell 钩子。

azd update 进入公开预览

azd update 现已在所有平台上推出公开预览版。单个命令即可处理更新，无论 azd 最初是如何安装的——不再需要单独追踪 Homebrew、WinGet 或 MSI 的路径。

通过 AZD_NON_INTERACTIVE 实现非交互模式

设置 AZD_NON_INTERACTIVE=true（或使用 --non-interactive / --no-prompt）现在会在 CI/CD 管道中产生一致、确定性的失败，当必需的输入无法自动解析时。此前各命令的行为不一致。

AI 模型配额预检查

azd provision 在尝试预配 AI 模型资源之前，会验证 Azure 认知服务配额。因配额限制而失败的部署现在会在流程早期显示错误，而不是在预配进行到一半时才报错。

Copilot 问题排查中的"修复此错误"

azd 的 Copilot 问题排查集成获得了直接应用建议修复的能力——而不仅仅是描述它。当代理识别出可修复的问题时，它可以直接在原地进行更改。

自定义预配提供程序和 Key Vault 密钥解析器

扩展作者现在可以使用 WithProvisioningProvider() 注册替代基础结构后端。另外，azd 在将配置传递给扩展之前会自动解析 @Microsoft.KeyVault(...) 引用，无需在自定义提供程序中手动解析密钥。

模板和监视模式的排除项

两个新的忽略文件对文件处理提供了更精细的控制：

.azdignore — 从模板副本中排除仅供贡献者使用的文件（文档、CI 配置），使最终用户获得干净的项目脚手架。
.azdxignore — 排除在 azd x watch 期间触发重新构建的目录，减少迭代开发过程中的噪音。

保留名称预检查和 docker.network 选项

azd 现在会在预配开始之前，当预测的资源名称包含 Azure 保留词（MICROSOFT、WINDOWS 或 LOGIN 前缀）时发出警告。新的 docker.network 选项将 --network 传递给 docker build，在需要特定 Docker 网络的企业代理环境中非常有用。

安全修复

Windows MSI 包现在包含代码签名验证。另一项修复关闭了可能在扩展命令边界之间暴露值的环境变量泄漏问题。

这是繁忙的一个月——多语言钩子支持尤其消除了不主要使用 Bash 的团队的一个真实摩擦点。有关所有五个版本的完整更改日志，请参阅完整发行说明。

Azure DevOps Server 2026年4月补丁 — PR完成修复和安全更新

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

本文为自动翻译。查看原文请点击这里。

给运行自托管Azure DevOps Server的团队快速提个醒：Microsoft发布了2026年4月补丁3，包含三个针对性修复。

修复内容

Pull Request完成失败 — 工作项自动完成期间的空引用异常可能导致PR合并失败。如果你遇到过随机的PR完成错误，这很可能就是原因
注销重定向验证 — 改进了注销期间的验证，以防止潜在的恶意重定向。这是一个值得尽快应用的安全修复
GitHub Enterprise Server PAT连接 — 创建到GitHub Enterprise Server的Personal Access Token连接之前无法正常工作，现在已恢复

如何更新

下载补丁3并运行安装程序。要验证补丁是否已应用：

<patch-installer>.exe CheckInstall

如果你在本地运行Azure DevOps Server，Microsoft强烈建议保持最新补丁，以确保安全性和可靠性。查看发行说明了解完整详情。

智能体平台工程正在成为现实 — Git-APE展示了方法

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

本文为自动翻译。查看原文请点击这里。

平台工程一直是那种在技术大会上听起来很棒的术语，但通常意味着"我们搭了一个内部门户和一个Terraform封装器。“真正的承诺 — 真正安全、受治理且快速的自助式基础设施 — 总是差那么几步。

Azure团队刚刚发布了智能体平台工程系列的第二部分，这次全是关于动手实现。他们称之为Git-APE（是的，这个缩写是故意的），这是一个开源项目，使用GitHub Copilot智能体加Azure MCP服务器，将自然语言请求转化为经过验证和部署的基础设施。

Git-APE究竟做什么

核心思路：开发者不再需要学习Terraform模块、浏览门户UI或向平台团队提交工单，而是直接和Copilot智能体对话。智能体理解意图、生成基础设施即代码、根据策略进行验证并部署 — 全部在VS Code内完成。

配置如下：

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

在VS Code中打开工作区，GitHub Copilot会自动发现智能体配置文件。你直接与智能体交互：

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

智能体在底层使用Azure MCP Server与Azure服务交互。VS Code设置中的MCP配置启用特定功能：

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

为什么这很重要

对于我们在Azure上构建的人来说，这将平台工程的对话从"如何构建一个门户"转变为"如何将我们的护栏描述为API。“当你的平台接口是AI智能体时，你的约束和策略的质量就成了产品本身。

第一部分博客阐述了理论：描述良好的API、控制模式和明确的护栏使平台做好了智能体化的准备。第二部分通过交付实际工具证明它确实有效。智能体不会盲目生成资源 — 它会根据最佳实践进行验证、遵守命名约定并应用你组织的策略。

清理同样简单：

@git-ape destroy my-resource-group

我的看法

说实话 — 这里更多是关于模式而非具体工具。Git-APE本身是一个演示/参考架构。但底层的理念 — 智能体作为平台的接口、MCP作为协议、GitHub Copilot作为宿主 — 这就是企业开发者体验的前进方向。

如果你是一个正在寻找如何让内部工具对智能体友好的平台团队，没有比这更好的起点了。如果你是.NET开发者想知道这和你的世界如何关联：Azure MCP Server和GitHub Copilot智能体可以与任何Azure工作负载配合使用。你的ASP.NET Core API、你的.NET Aspire技术栈、你的容器化微服务 — 都可以成为智能体部署流程的目标。

总结

Git-APE是对智能体平台工程实践的一个早期但具体的展示。克隆仓库，试试演示，开始思考你的平台的API和策略需要是什么样子，才能让智能体安全地使用它们。

阅读完整文章获取详细教程和演示视频。

Azure DevOps终于修好了所有人都在抱怨的Markdown编辑器

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

本文为自动翻译。查看原始版本，请点击这里。

如果你使用Azure Boards，你可能经历过这种情况：你在阅读一个工作项描述，也许在检查验收标准，然后不小心双击了。砰——你进入了编辑模式。你根本不想编辑任何东西。你只是在阅读。

Dan Hellem 宣布了这个修复，这是那种听起来很小但确实从日常工作流中消除了真正摩擦的改动。

什么变了

工作项文本字段的Markdown编辑器现在默认以预览模式打开。你可以阅读和交互内容——跟随链接、检查格式——不用担心意外进入编辑模式。

当你真的想要编辑时，点击字段顶部的编辑图标。完成后，显式退出到预览模式。简单、有意图、可预测。

为什么这比听起来更重要

社区反馈帖子很长。双击编辑的行为是在2025年7月随Markdown编辑器引入的，投诉几乎立刻开始了。

对于使用Azure Boards进行冲刺计划、需求梳理或代码审查的团队来说，这种微摩擦会累积。

部署状态

已经在向部分客户推出，将在未来两到三周内扩展到所有人。

总结

不是每个改进都需要成为头条功能。有时候最好的更新就是简单地移除恼人的东西。这就是其中之一——一个小小的UX修复，让Azure Boards对只想安静阅读工作项的人变得不再那么敌意。

Azure DevOps MCP Server 登陆 Microsoft Foundry：这对你的 AI 代理意味着什么

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

MCP（Model Context Protocol）正在迎来它的高光时刻。如果你一直在关注 AI 代理生态系统，你可能已经注意到 MCP 服务器到处涌现 — 通过标准化协议赋予代理与外部工具和服务交互的能力。

现在 Azure DevOps MCP Server 已在 Microsoft Foundry 中可用，这是那种让你思考实际可能性的集成之一。

这里到底发生了什么

Microsoft 已经发布了 Azure DevOps MCP Server 的公开预览版 — 那是 MCP 服务器本身。新的是 Foundry 集成。你现在可以直接从工具目录将 Azure DevOps MCP Server 添加到 Foundry 代理中。

对于还不熟悉 Foundry 的人：它是 Microsoft 用于大规模构建和管理 AI 驱动应用程序和代理的统一平台。模型访问、编排、评估、部署 — 全部在一个地方。

配置

配置出奇地简单：

在你的 Foundry 代理中，进入 Add Tools > Catalog
搜索 “Azure DevOps”
选择 Azure DevOps MCP Server（preview）并点击 Create
输入你的组织名称并连接

就这样。你的代理现在可以访问 Azure DevOps 工具了。

控制代理可以访问什么

这是我欣赏的部分：你不会被困在全有或全无的方式中。你可以指定哪些工具对代理可用。如果你只想让它读取工作项但不碰管道，可以这样配置。最小权限原则，应用到你的 AI 代理上。

这在企业场景中很重要，你不希望一个代理因为有人让它"帮忙发布"就意外触发部署管道。

为什么这对 .NET 团队很有趣

想想这在实践中能实现什么：

冲刺规划助手 — 可以拉取工作项、分析速度数据并建议冲刺容量的代理
代码审查机器人 — 因为能实际读取你的仓库和关联的工作项，所以理解你的 PR 上下文的代理
事件响应 — 可以创建工作项、查询最近的部署并将 bug 与最近的更改关联的代理
开发者入职 — “我应该做什么？“得到基于实际项目数据的真实回答

对于已经在 CI/CD 管道和项目管理中使用 Azure DevOps 的 .NET 团队来说，拥有一个能直接与这些系统交互的 AI 代理是迈向有用自动化的重要一步。

更大的 MCP 图景

这是更广泛趋势的一部分：MCP 服务器正在成为 AI 代理与外部世界交互的标准方式。我们在 GitHub、Azure DevOps、数据库、SaaS API 中都能看到它们 — 而 Foundry 正在成为所有这些连接汇聚的中心。

如果你在 .NET 生态系统中构建代理，MCP 值得关注。协议是标准化的，工具正在成熟，Foundry 集成使其无需手动配置服务器连接即可访问。

总结

Foundry 中的 Azure DevOps MCP Server 目前处于预览阶段，所以预计它会继续发展。但核心工作流是可靠的：连接、配置工具访问，让你的代理使用你的 DevOps 数据工作。如果你已经在 Foundry 生态系统中，只需几次点击就能开始。试试看你能构建什么工作流。

查看完整公告获取完整的配置步骤和更多详情。