Azure DevOps 路线图
| 新增| | |
产品路线图
此功能列表可查看我们的路线图。 它确定了我们目前正在处理的一些重要功能,以及你期望看到这些功能的大致时间范围。 它并不全面,但旨在提供对关键投资的一些可见性。 在顶部,你将找到我们大型多季度计划的列表,以及它们分解的功能。 接下来,你将找到我们计划的重要功能的完整列表。
每个功能都链接到一篇文章,你可以在其中了解有关特定项的详细信息。 这些功能和日期是当前计划,可能会更改。 时间范围列反映我们预期该功能可用的时间。
计划
适用于 Azure DevOps 的 GitHub Advanced Security
Azure DevOps 的 GitHub 高级安全性(GHAS)现已正式发布。 现在,任何项目集合管理员都可以从“项目设置”或“组织设置”中为其组织、项目和存储库启用高级安全性。 可以在我们的 文档中详细了解如何为 Azure DevOps 配置 GitHub 高级安全性。
我们期望提供的新功能包括:
功能 | 区域 | 季度 |
---|---|---|
显示上下文注释以包含新引入的高级安全发现拉取请求 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2025 年第 1 季度 |
确定检测到的合作伙伴机密有效性 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2025 年第 1 季度 |
使用 Dependabot 安全更新自动修复检测到的依赖项扫描漏洞 | 适用于 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 | 常规 | ![]() |
个人访问令牌的控制平面 (PAT) | 常规 | ![]() |
托管标识和服务主体支持(预览版) | 常规 | ![]() |
Azure 部署的工作负荷标识联合(预览版) | 管道 | ![]() |
Azure Active Directory OAuth 的粒度范围 | 常规 | ![]() |
托管标识和服务主体支持 (GA) | 常规 | ![]() |
Azure 服务连接的工作负荷标识联合身份验证 (GA) | 管道 | ![]() |
Docker 服务连接的工作负荷标识联合身份验证 | 管道 | ![]() |
条件访问策略的完整 Web 支持 | 常规 | ![]() |
禁用个人访问令牌(PAT)使用的策略 | 常规 | 2025 年第 1 季度 |
新的管道服务连接类型,用于通过 Azure DevOps 进行身份验证 | 管道 | 2025 年第 1 季度 |
使用 Entra 发布的令牌进行工作量身份联合 | 管道 | 2025 年第二季度 |
改进的 Boards + GitHub 集成
现有的 Azure Boards + GitHub 集成已到位多年。 集成是一个很好的起点,但它不提供客户习惯的可追溯性级别。 根据客户反馈,我们汇集了一组投资来增强这种集成。 我们的目标是改进它,以便选择使用 GitHub 存储库的 Azure Boards 客户可以保持与在 Azure DevOps 中创建存储库的同等级别的可跟踪性。
这些投资包括:
功能 | 区域 | 季度 |
---|---|---|
从工作项添加指向 GitHub 提交或拉取请求的链接 | Boards | ![]() |
显示有关 GitHub 拉取请求的更多详细信息 | Boards | ![]() |
在搜索和链接 GitHub 时提高可伸缩性 存储库到 Azure DevOps 项目 |
Boards | ![]() |
GitHub 上的 AB# 链接拉取请求(预览版) | Boards | ![]() |
从工作项在 GitHub 存储库上创建分支 | Boards | ![]() |
支持具有数据驻留的 GitHub Enterprise Cloud | Boards | ![]() |
! 提及对 GitHub 拉取请求 的支持 | Boards | 2025 年第 1 季度 |
使用 YAML 生成管道时,显示生成状态 GitHub 存储库 |
Boards | 2025 年第 1 季度 |
合并 GitHub Pull Request 时支持状态变更 | Boards | 2025 年第 1 季度 |
链接到 GitHub 分支时自动链接拉取请求 | Boards | 2025 年第 1 季度 |
自动链接合并提交 | Boards | 2025 年第 1 季度 |
当相应条件满足时,自动删除分支链接 GitHub 分支已被删除 |
Boards | 2025 年第 1 季度 |
YAML 和发布管道功能奇偶校验
在过去的几年里,我们所有的管道投资都在 YAML 管道领域。 此外,我们的所有安全改进都适用于 YAML 管道。 例如,使用 YAML 管道时,对 受保护资源 (例如存储库、服务连接等)的控制掌握在资源所有者手中,而不是管道作者。 YAML 管道中使用的作业访问令牌的范围限定为 YAML 文件中指定的特定存储库。 这只是可用于 YAML 管道的两个安全功能示例。 出于这些原因,我们建议将 YAML 管道用于经典管道。 在经典版本上采用 YAML 对于生成(CI)来说非常重要。 但是,许多客户在 YAML 上继续使用经典发布管理管道进行发布(CD)。 主要原因是这两种解决方案之间各种 CD 功能缺乏奇偶校验。 在过去的一年里,我们解决了这一领域的几个差距,特别是在检查中。 检查是 YAML 管道中的主要机制,用于将生成从一个阶段提升到另一个阶段。 我们将在未来一年内继续解决其他领域的差距。 我们的重点是用户体验、可跟踪性和环境。
功能 | 区域 | 季度 |
---|---|---|
审核检查 | 管道 | ![]() |
检查中的自定义变量 | 管道 | ![]() |
检查可伸缩性 | 管道 | ![]() |
绕过审批和检查 | 管道 | ![]() |
排序审批和其他检查 | 管道 | ![]() |
延迟审批 | 管道 | ![]() |
重新运行单阶段 | 管道 | ![]() |
阶段手动排队 | 管道 | ![]() |
阶段级并发 | 管道 | ![]() |
阶段级可跟踪性 | 管道 | 2025 年第二季度 |
按需不按顺序执行阶段 | 管道 | 2025 年第二季度 |
检查中的服务连接 | 管道 | 未来 |
检查扩展性 | 管道 | 未来 |
Azure 测试计划改进
Azure DevOps 提供各种测试工具和集成,以支持不同的测试需求。 其中包括手动测试、自动化测试和探索性测试。 该平台允许创建和管理测试计划和测试套件,这些计划和套件可用于跟踪冲刺或里程碑的手动测试。 此外,Azure DevOps 与 CI/CD 管道集成,可实现自动化测试执行和报告。
我们正在加大对这一领域的投资力度,以响应我们最活跃的客户群的反馈。 我们的重点是测试管理的以下方面:改进端到端测试的可追溯性;扩展对测试计划中自动测试的各种编程语言和框架的支持;重新设计用于使用测试运行和测试结果的工作流和体验。
下面,你将找到我们打算在此计划中交付的多项投资:
功能 | 区域 | 季度 |
---|---|---|
在 Azure 测试计划中支持 JUnit/Java | 测试计划 | 2025 年第 1 季度 |
Azure 测试计划中对 Pytest/Python 的支持 | 测试计划 | 2025 年第 1 季度 |
使用 REST API 还原已删除的测试计划和测试套件 | 测试计划 | 2025 年第 1 季度 |
自动暂停手动测试用例运行 | 测试计划 | 2025 年第 1 季度 |
快速访问测试用例中的测试结果 | 测试计划 | 2025 年第二季度 |
恢复暂停的测试用例 | 测试计划 | 2025 年第二季度 |
全新试运行体验 | 测试计划 | 2025 年第二季度 |
高级测试用例结果历史记录 | 测试计划 | 2025 年第二季度 |
所有功能
Azure DevOps Services
Azure DevOps Server
如何提供反馈
我们很想听听你对这些功能的看法。 通过开发者社区报告任何问题或建议功能。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。