Azure DevOps 路线图
| 新增 | 功能开发者社区 | DevOps 博客文档 | |
产品路线图
此功能列表可查看我们的路线图。 它确定了我们目前正在处理的一些重要功能，以及你期望看到这些功能的大致时间范围。 它并不全面，但旨在提供对关键投资的一些可见性。 在顶部，你将找到我们大型多季度计划的列表，以及它们分解的功能。 接下来，你将找到我们计划的重要功能的完整列表。
每个功能都链接到一篇文章，你可以在其中了解有关特定项的详细信息。 这些功能和日期是当前计划，可能会更改。 时间范围列反映我们预期该功能可用的时间。
计划
适用于 Azure DevOps 的 GitHub Advanced Security
Azure DevOps 的 GitHub 高级安全性（GHAS）现已正式发布。 现在，任何项目集合管理员都可以从“项目设置”或“组织设置”中为其组织、项目和存储库启用高级安全性。 可以在我们的 文档中详细了解如何为 Azure DevOps 配置 GitHub 高级安全性。
我们期望提供的新功能包括：
| 功能 | 区域 | 季度 |
|---|---|---|
| 显示上下文注释以包含新引入的高级安全发现拉取请求 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2024 年第 4 季度 |
| 确定检测到的合作伙伴机密有效性 | 适用于 Azure DevOps 的 GitHub Advanced Security | 2024 年第 4 季度 |
| 使用 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 | 常规 |  2022 年第 4 季度 |
| 个人访问令牌的控制平面 （PAT） | 常规 | 2022 年第 4 季度 |
| 托管标识和服务主体支持（预览版） | 常规 | 2023 年第 1 季度 |
| Azure 部署的工作负荷标识联合（预览版） | 管道 | 2023 年第 3 季度 |
| Azure Active Directory OAuth 的粒度范围 | 常规 | 2023 年第 3 季度 |
| 托管标识和服务主体支持 （GA） | 常规 | 2023 年第 3 季度 |
| Azure 服务连接的工作负荷标识联合身份验证 （GA） | 管道 | 2024 年第 1 季度 |
| Docker 服务连接的工作负荷标识联合身份验证 | 管道 | 2024 H2 |
| 条件访问策略的完整 Web 支持 | 常规 | 2024 H2 |
| 禁用身份验证方法的策略 | 常规 | 未来 |
改进的 Boards + GitHub 集成
现有的 Azure Boards + GitHub 集成已到位多年。 集成是一个很好的起点，但它不提供客户习惯的可追溯性级别。 根据客户反馈，我们汇集了一组投资来增强这种集成。 我们的目标是改进它，以便选择使用 GitHub 存储库的 Azure Boards 客户可以保持与在 Azure DevOps 中创建存储库的同等级别的可跟踪性。
这些投资包括：
| 功能 | 区域 | 季度 |
|---|---|---|
| 从工作项添加指向 GitHub 提交或拉取请求的链接 | Boards | 2024 年第 1 季度 |
| 显示有关 GitHub 拉取请求的更多详细信息 | Boards | 2024 年第 1 季度 |
| 在搜索和链接 GitHub 时提高可伸缩性 存储库到 Azure DevOps 项目 |
Boards | 2024 年第 2 季度 |
| GitHub 上的 AB# 链接拉取请求（预览版） | Boards | 2024 年第 2 季度 |
| 从工作项在 GitHub 存储库上创建分支 | Boards | 2024 年第 3 季度 |
| 支持具有数据驻留的 GitHub Enterprise Cloud | Boards | 2024 年第 4 季度 |
| ! 提及对 GitHub 拉取请求 的支持 | Boards | 2025 年第 1 季度 |
| 在 GitHub 存储库中使用 YAML 生成管道时显示生成状态 | Boards | 2025 年第 1 季度 |
| 将 YAML 发布管道与 GitHub 存储库配合使用时向工作项报告阶段状态 | Boards | 未来 |
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 季度 |
| 阶段级可跟踪性 | 管道 | 2024 H2 |
| 检查中的服务连接 | 管道 | 未来 |
| 检查扩展性 | 管道 | 未来 |
所有功能
Azure DevOps Services
Azure DevOps Server
如何提供反馈
我们很想听听你对这些功能的看法。 通过开发者社区报告任何问题或建议功能。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。