Features
Azure Pipelines 中的工作负荷身份联合（公共预览版）
是否停止在 Azure 服务连接中存储机密和证书？ 想要停止为这些机密在到期时何时轮换而担心吗？ 现在，我们宣布了 Azure 服务连接的工作负载身份联合公测版。工作负载身份联合 使用行业标准技术 Open ID Connect （OIDC），以简化 Azure Pipelines 与 Azure 之间的身份验证。 为方便身份验证，使用了联合身份验证而非密码。
作为此功能的一部分，Azure （ARM） 服务连接已使用另一个方案进行更新，以支持工作负荷标识联合。 这允许使用 Azure 服务连接的管道任务通过联合主体（sc://<org>/<project>/<service connection name>）进行身份验证。 相比现有身份验证方案，使用此方案的主要优点如下：
- 简化的管理：不再将机密从 Azure AD 中的服务主体生成、复制和存储到 Azure DevOps。 在 Azure 服务连接的其他身份验证方案中使用的机密（例如服务主体）在一定期限（目前为两年）后过期。 当管道过期时，它们会失败。 必须重新生成新的机密并更新服务连接。 切换到工作负荷标识联合可以消除管理这些机密的需要，并改善创建和管理服务连接的整体体验。
- 提高了安全性：使用工作负荷标识联合身份验证时，Azure Pipelines 与 Azure 之间的通信中没有涉及永久性机密。 因此，管道作业中运行的任务无法泄露或窃取能够访问生产环境的机密。 这通常是我们的客户关注的问题。
可以通过两种方式利用这些功能：
- 每当创建新的 Azure 服务连接时，请使用 新的工作负荷标识联合方案 。 今后，这是建议的机制。
- 将 现有的 Azure 服务连接（基于机密）转换为新方案。 可以一次转换一个连接。 最重要的是，无需修改使用这些服务连接的任何管道。 完成转换后，它们将自动应用新方案。
若要使用工作负荷标识联合创建新的 Azure 服务连接，只需在 Azure 服务连接创建体验中选择工作负荷标识联合身份验证（自动）或（手动）：
若要转换以前创建的 Azure 服务连接，请在选择连接后选择“转换”作：
Azure Pipelines 附带的所有 Azure 任务现在都支持此新方案。 但是，如果使用来自市场的任务或本地自定义任务部署到 Azure，则它可能尚不支持工作负荷标识联合。 在这些情况下，我们要求您更新任务以支持工作负载身份联合，以提高安全性。 可 在此处找到受支持的任务的完整列表。
对于此预览版，我们仅支持 Azure 服务连接的工作负荷标识联合。 此方案不适用于任何其他类型的服务连接。 有关更多详细信息，请参阅我们的文档。
此博客文章 包含更多详细信息。
可以使用 Microsoft Entra ID（而不是 PAT）来注册流水线代理
流水线代理现在支持使用服务主体或用户注册代理的更多参数选项。 您应在其安全设置中授予所用身份对代理池的访问权限。 这样就无需使用个人访问令牌（PAT）进行代理的一次性设置。
使用服务主体注册代理
若要使用服务主体向 Azure DevOps Services 注册 Pipelines 代理，请提供下列参数：
--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee
在代理 VM 扩展中使用服务主体
可以使用 VM 扩展将 Azure VM 包含在部署组中。 VM 扩展已更新，现在使用服务主体而不是 PAT 来注册代理：
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
使用设备代码流以交互方式注册代理
可以使用 Web 浏览器轻松完成设置。 运行代理配置脚本时，输入 “AAD” 作为身份验证类型。 该脚本将指导你完成后续步骤，包括转到 Web 的位置和要输入的代码。 在 Web 上输入代码后，返回到控制台以完成代理设置。
适用于环境的 REST API
环境是一个资源集合，您可以将管道中的部署定位于此。 环境提供部署历史记录、工作项和提交的可追踪性，以及访问控制机制。
我们知道你想要 以编程方式创建环境，因此我们发布了其 REST API 的文档。
防止意外的管道运行
现在，如果 YAML 管道未指定 trigger 部分，则会针对推送到其存储库的任何更改来运行。 这可能会让人对管道为何运行感到困惑，并导致许多意料之外的运行。
我们添加了一个名为 “禁用隐含 YAML CI 触发器 ”的组织级和项目级管道设置，可用于更改此行为。 如果缺少管道的触发器部分，可以选择不触发管道。
默认情况下，安全地生成 GitHub 存储库
最后一次冲刺，我们引入了一个 集中控件，用于从分支 GitHub 存储库生成 PR。
通过此次冲刺，我们将在组织级别为新成立的组织启用 Securely build pull requests from forked repositories 选项。 现有组织不受影响。
禁用了在生成失败时将代码覆盖率策略状态覆盖为“失败”
之前，如果 PR 中的构建失败，则代码覆盖率策略状态将被重写为“失败”。 对于一些将构建设置为可选检查并将代码覆盖率策略设置为必需检查的用户，这成为了一个阻碍因素，导致他们的 PR 被阻止。
在本次sprint中，如果生成失败，代码覆盖率策略不会被改写为“失败”。 将为所有客户启用此功能。
后续步骤
注释
这些功能将在未来两到三周内推出。
请去 Azure DevOps 上看看。
如何提供反馈
我们很乐意听到你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。