| 新增功能 | 开发者社区 | DevOps 博客 | 文档 |
产品路线图
此功能列表可让您一窥我们的路线图。 它确定了我们目前正在处理的一些重要功能，以及你期望看到这些功能的大致时间范围。 它并不全面，但旨在提供对关键投资的一些可见性。 顶部显示我们的大型多季度计划及其细分功能的列表。 接下来，你将找到我们计划的重要功能的完整列表。
每个功能都链接到一篇文章，你可以在其中了解有关特定项的详细信息。 这些功能和日期是当前计划，可能会更改。 时间范围列反映我们预期该功能可用的时间。
倡议
适用于 Azure DevOps 的 GitHub Advanced Security
GitHub Advanced Security for Azure DevOps （GHAzDO）在附加许可证下为 Azure DevOps 带来了额外的安全功能。 现在，任何项目集合管理员都可以从“项目设置”或“组织设置”中为其组织、项目和存储库启用高级安全性。
适用于 Azure DevOps 的 GitHub 高级安全性的主要功能包括：
- 机密扫描： 检测和修正 git 存储库中的纯文本机密。 如果启用了推送保护，它还会检测并阻止机密，然后再将其推送到存储库。
- 代码扫描： 使用 CodeQL 或第三方工具搜索代码中的潜在安全漏洞和编码错误。
- 依赖项扫描： 当代码依赖于不安全的包并接收简单的修正指南时检测并发出警报。
可以在我们的 文档中详细了解如何为 Azure DevOps 配置 GitHub 高级安全性。
我们预计即将提供的功能包括：
| 功能 | 区域 | 季度 |
|---|---|---|
| 确定检测的合作伙伴机密有效性 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2025 年第二季度 |
| 将 Boards 项链接到高级安全警报 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2025 年第 3 季度 |
| 使用 Dependabot 安全更新自动修复检测到的依赖项扫描漏洞 | 适用于 Azure DevOps 的 GitHub Advanced Security | 未来 |
| CodeQL 默认设置（一键启用） | 适用于 Azure DevOps 的 GitHub Advanced Security | 未来 |
最大程度地降低与凭据被盗相关的风险
Azure DevOps 支持许多不同的身份验证机制，包括基本身份验证、个人访问令牌（PAT）、SSH 和Microsoft Entra ID（前为 Azure Active Directory）访问令牌。 这些机制不是从安全角度平等创建的，尤其是在凭据被盗的可能性方面。 例如，意外泄露凭据（如 PAT）可以让恶意参与者进入 Azure DevOps 组织，以便他们能够访问关键资产（如源代码），转向供应链攻击，甚至转向破坏生产基础结构。 为了最大程度地降低凭据被盗的风险，我们将在以下几个方面集中精力：
使管理员能够通过控制平面策略提高身份验证安全性。
通过添加对更安全的替代方法的支持，减少对 PAT 和其他可窃取机密的需求。
深化 Azure DevOps 与 Microsoft Entra ID 的集成，以更好地支持其各种安全功能。
避免需要在 Azure Pipelines 服务连接中存储生产机密。
| 功能 | 区域 | 季度 |
|---|---|---|
| PAT 生命周期 API | 常规 |
2022 年第 4 季度 |
| 个人访问令牌 (PAT) 的控制平面 | 常规 |
2022 年第 4 季度 |
| 托管标识和服务主体支持（预览版） | 常规 |
2023 年第 1 季度 |
| Azure 部署的工作负荷联合身份验证（预览版） | 管道 |
2023 年第 3 季度 |
| Azure Active Directory OAuth 的精细范围 | 常规 |
2023 年第 3 季度 |
| 托管标识和服务主体支持（正式发布版本） | 常规 |
2023 年第 3 季度 |
| Azure 服务连接的工作负荷联合身份验证（正式发布版本） | 管道 |
2024 年第 1 季度 |
| Docker 服务连接的工作负荷联合身份验证 | 管道 |
2024 H2 |
| 条件访问策略的完整 Web 支持 | 常规 |
2024 Q4 |
| 禁用个人访问令牌（PAT）使用的策略 | 常规 | 2025 年第二季度 |
| 使用 Entra 发布的令牌进行工作量身份联合 | 管道 | 2025 年第二季度 |
| 从管道任务到 Azure DevOps API 的无 PAT 身份验证 | 管道 | 2025 年第 3 季度 |
| 连续访问评估 | 常规 | 未来 |
| 在 Azure DevOps 中使用设备绑定的 Entra 令牌 | 常规 | 未来 |
改进的 Boards + GitHub 集成
现有的 Azure Boards + GitHub 集成已到位多年。 集成是一个很好的起点，但它不提供客户已经习惯的可追溯性级别。 根据客户反馈，我们汇集了一组投资来增强这种集成。 我们的目标是改进它，以便选择使用 GitHub 存储库的 Azure Boards 客户可以保持与在 Azure DevOps 中创建存储库的同等级别的可跟踪性。
这些投资包括：
| 功能 | 区域 | 季度 |
|---|---|---|
| 在工作项中添加指向 GitHub 提交或拉取请求的链接 | 董事会 |
2024 年第 1 季度 |
| 显示有关 GitHub 拉取请求的更多详细信息 | 董事会 |
2024 年第 1 季度 |
|
在搜索和链接 GitHub 时提高可伸缩性 存储库到 Azure DevOps 项目 |
董事会 |
2024 年第 2 季度 |
| GitHub 拉取请求上的 AB# 链接 | 董事会 |
2024 年第 2 季度 |
| 从工作项在 GitHub 存储库上创建分支 | 董事会 |
2024 年第 3 季度 |
| 自动链接合并提交 | 董事会 |
2025 年第 1 季度 |
| 链接到 GitHub 分支时自动链接拉取请求 | 董事会 |
2025 年第 1 季度 |
|
当相应条件满足时，自动删除分支链接 GitHub 分支已被删除 |
董事会 |
2025 年第 1 季度 |
|
使用 YAML 生成管道时，显示生成状态 GitHub 存储库 |
董事会 |
2025 年第 1 季度 |
| 合并 GitHub Pull Request 时支持状态变更 | 董事会 |
2025 年第 2 季度 |
| ! 提及对 GitHub 拉取请求的支持 | 董事会 |
2025 年第 2 季度 |
| MCP Server for Azure DevOps | 常规 | 2025 年第二季度 |
| 支持具有数据驻留的 GitHub Enterprise Cloud | 董事会 | 2025 年第二季度 |
迁移到托管 DevOps 池
托管的 DevOps 池是 Azure DevOps 虚拟机规模集代理池的发展。 它提供更好的池可伸缩性和可靠性，简化了池管理，并允许在自定义 Azure VM 上使用Microsoft托管代理中的 VM 映像。 可以 在此处阅读有关托管 DevOps 池的详细信息。 托管 DevOps 池已正式发布，因此，你可以将虚拟机规模集池迁移到托管 DevOps 池，并尽可能将其用于生产工作流。
下面，你会发现我们计划作为此计划一部分提供的多项投资：
| 功能 | 区域 | 季度 |
|---|---|---|
| 使用项目级别权限在 Azure DevOps 项目级别创建池 | 管道 | 2025 年第二季度 |
| 现成虚拟机实例 | 管道 | 2025 年第二季度 |
| 添加受信任的根证书 | 管道 | 2025 年第二季度 |
| 基于容器的代理 | 管道 | 2025 年第 4 季度 |
YAML 和发布管道功能奇偶一致性
在过去的几年里，我们所有的管道投资都在 YAML 管道领域。 此外，我们的所有安全改进都适用于 YAML 管道。 例如，使用 YAML 管道时，对 受保护资源 （例如存储库、服务连接等）的控制掌握在资源所有者手中，而不是管道作者。 YAML 管道中使用的作业访问令牌的范围限定为 YAML 文件中指定的特定存储库。 这只是可用于 YAML 管道的两个安全功能示例。 出于这些原因，我们建议使用 YAML 管道，而不是经典管道。 采用 YAML 取代经典版本对构建（CI）来说意义重大。 然而，许多客户继续在 YAML 上使用经典发布管理管道来发布 (CD)。 主要原因是这两种解决方案的各种 CD 功能之间缺乏一致性。 在过去的一年里，我们解决了这一领域的几个差距，特别是在检查中。 检查是 YAML 管道中的主要机制，用于将生成从一个阶段提升到另一个阶段。 我们将在未来一年内继续解决其他领域的差距。 我们的重点是用户体验、可跟踪性和环境。
| 功能 | 区域 | 季度 |
|---|---|---|
| 审核检查 | 管道 |
2022 年第 4 季度 |
| 检查中的自定义变量 | 管道 |
2023 年第 1 季度 |
| 检查可伸缩性 | 管道 |
2023 年第 2 季度 |
| 绕过审批和检查 | 管道 |
2023 年第 4 季度 |
| 排序审批和其他检查 | 管道 |
2024 年第 1 季度 |
| 延迟审批 | 管道 |
2024 年第 1 季度 |
| 重新运行单个阶段 | 管道 |
2024 年第 1 季度 |
| 手动安排阶段队列 | 管道 |
2024 H2 |
| 阶段级并发 | 管道 |
2024 年第 3 季度 |
| 阶段级可跟踪性 | 管道 | 2025 年第二季度 |
| 按需不按顺序执行阶段 | 管道 | 2025 年第二季度 |
| 检查中的服务连接 | 管道 | 未来 |
| 检查扩展性 | 管道 | 未来 |
Azure 测试计划改进
Azure DevOps 提供各种测试工具和集成，以支持不同的测试需求。 其中包括手动测试、自动化测试和探索性测试。 该平台允许创建和管理测试计划和测试套件，这些计划和套件可用于跟踪冲刺或里程碑的手动测试。 此外，Azure DevOps 与 CI/CD 管道集成，可实现自动化测试执行和报告。
我们正在加大对这一领域的投资力度，以响应我们最活跃的客户群的反馈。 我们的重点是测试管理的以下方面：改进端到端测试的可追溯性；扩展对测试计划中自动测试的各种编程语言和框架的支持；重新设计用于使用测试运行和测试结果的工作流和体验。
下面，你将找到我们打算在此计划中交付的多项投资：
| 功能 | 区域 | 季度 |
|---|---|---|
| 使用 REST API 还原已删除的测试计划和测试套件 | 测试计划 |
2025 年第 1 季度 |
| 自动暂停手动测试用例运行 | 测试计划 |
2025 年第 1 季度 |
| 在 Azure 测试计划中支持 YAML 管道 | 测试计划 | 2025 年第二季度 |
| Azure 测试计划中对 Java （JUnit） 的支持 | 测试计划 | 2025 年第二季度 |
| Azure 测试计划中对 Python （PyTest） 的支持 | 测试计划 | 2025 年第二季度 |
| Azure 测试计划中对 JavaScript （Jest） 的支持 | 测试计划 | 2025 年第二季度 |
| 默认恢复已暂停的测试用例 | 测试计划 | 2025 年第二季度 |
| 快速访问测试用例中的测试结果 | 测试计划 | 2025 年第二季度 |
| 高级测试用例结果历史记录 | 测试计划 | 2025 年第二季度 |
| 要求中的最新测试结果 | 测试计划 | 2025 年第二季度 |
| 在“执行”选项卡中查看测试用例状态 | 测试计划 | 2025 年第二季度 |
| 新的测试计划目录 | 测试计划 | 2025 年第二季度 |
| 新的测试运行体验 - 公共预览版 | 测试计划 | 2025 年第 3 季度 |
| 增强的测试点结果面板 | 测试计划 | 2025 年第 3 季度 |
| Azure 测试计划中对 JavaScript （Playwright） 的支持 | 测试计划 | 2025 年第 3 季度 |
所有功能
Azure DevOps Services
Azure DevOps Server
如何提供反馈
我们很想听听你对这些功能的看法。 通过开发者社区报告任何问题或建议功能。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。