增强安全性和工作流效率

此冲刺带来了各种改进，重点是提高安全性和简化工作流效率。 在这些改进中，Azure Pipelines 中的服务连接创建体验。 这使团队能够使用具有工作负荷标识联合的现有托管标识来设置服务连接。 它还简化了配置并降低了特权标识的风险。

此外，我们很高兴地宣布，在 Azure Repos 中，带有美人鱼语法的 markdown 文件现在将以文件预览和拉取请求中的图表形式呈现，从而为文档提供更清晰的视觉对象。

最后，在 GitHub 高级安全性中，拉取请求批注现在提供依赖项和代码扫描的内联通知，简化了团队在代码评审期间检测和解决潜在问题的过程。

有关详细信息，请查看发行说明。

常规

• 将代码块复制到剪贴板
• Microsoft Entra 配置文件信息（预览版）

适用于 Azure DevOps 的 GitHub Advanced Security

• 拉取依赖项和代码扫描的请求批注
• 用于依赖项扫描的新 pip 检测策略

Azure Boards：

• 工作项窗体上的增强标记管理
• 改进了工作项注释中的图像支持
• GitHub 拉取请求见解

Azure Repos

• 为拉取请求配置目标分支
• 在 Markdown 文件预览中支持美人鱼图

Azure Pipelines

• Azure Pipelines 托管代理上的 Ubuntu 24.04
• 在 Azure 集成测试中使用工作负荷标识联合身份验证
• 通过改进的托管标识支持创建新的 Azure 服务连接体验
• 父阶段失败时运行子阶段

Azure Artifacts

• 使用公共源和 Cargo 向 Azure Artifacts 进行身份验证

Wiki

• 改进将基于 HTML 的内容粘贴到 Wiki

常规

将代码块复制到剪贴板

为了响应开发人员社区的反馈，我们引入了“复制到剪贴板”按钮，用于呈现的 Markdown 中的所有代码块。 此增强功能可用于 Wiki 页面、Repos 中的 Markdown 文件预览、拉取请求讨论和说明以及工作项讨论。

Microsoft Entra 配置文件信息（预览版）

我们很高兴在 Azure DevOps 中引入 Microsoft Entra 配置文件信息的集成，从而不再需要单独的配置文件更新。 若要试用预览版，请在预览功能中启用Microsoft Entra 配置文件信息。

启用后，配置文件 设置 是只读的，并且会自动从 Microsoft Entra 填充。 若要还原到以前的设置或提供反馈，请关闭预览并共享评论。

适用于 Azure DevOps 的 GitHub Advanced Security

拉取依赖项和代码扫描的请求批注

作为高级安全路线图的一部分， 拉取请求注释 现已推出。 你将在任何使用与生成验证策略关联的管道（包括依赖项和/或代码扫描任务）的拉取请求上收到内联批注。

除了为相关分支创建生成验证策略之外，不需要任何其他选择加入。

Show more details单击批注可转到有关警报的警报详细信息视图。

有关详细信息，请参阅此处 的最新博客文章

用于依赖项扫描的新 pip 检测策略

依赖项扫描现在使用 Python 的新检测策略：PipReport，基于 pip 安装报告 功能。 此更新通过遵循环境说明符来确定实际 pip install 运行将检索的确切版本来提高准确性。 默认情况下，检测器用于pypi.org生成依赖项关系图。 （可选）可以设置管道环境变量，PIP_INDEX_URL以改为构造依赖项关系图。 如果访问源时存在身份验证问题，可能需要 PipAuthenticate@1 设置管道任务，以便可以访问源。

有关检测策略的详细信息，请参阅 Pip 检测 文档。

Azure Boards

工作项窗体上的增强标记管理

Azure Boards 中的标记管理已得到增强，以提供更简化的体验。 已删除的标记不再显示在工作项窗体的建议列表中，确保仅显示活动标记。

改进了工作项注释中的图像支持

我们改进了将图像粘贴到工作项批注中的支持。 现在可以将图像直接从Microsoft Teams、电子邮件和 Word 文档等源粘贴到工作项的讨论部分

GitHub 拉取请求见解

我们增强了 GitHub 拉取请求 与 Azure Boards 之间的集成。 除了显示打开状态和关闭状态之外，现在还可以查看拉取请求是否处于草稿模式、需要审阅和检查状态。 无需打开拉取请求即可。

若要启用此功能，请确保转到 GitHub 中的 Boards 应用，接受请求的已更新权限以读取和写入检查。

Azure Repos

为拉取请求配置目标分支

管理存储库中的多个分支可能非常困难，尤其是在创建新的拉取请求时。 使用新的“为拉取请求配置目标分支”功能，现在可以指定首选目标分支的列表，确保拉取请求建议更准确且更相关。 这有助于简化工作流，并减少针对错误分支的可能性。 若要使用此功能，请在存储库的默认分支中创建.azuredevops/pull_request_targets.yml文件。 此 YAML 文件应包含标题为 pull_request_targets 与候选分支匹配的分支名称或前缀的列表。 例如：

pull_request_targets:
  - main
  - release/*
  - feature/*

在此配置中，主分支的优先级是优先的，但从或feature/适当时考虑的分支release/。 配置在以下方案中应用：

• 拉取请求建议：将分支推送到 Azure DevOps 后，Repos 页可能会建议从该分支创建拉取请求，从而动态选择目标分支。
• 拉取请求 URL：使用 sourceRef 参数直接导航到拉取请求创建页面但省略 targetRef 参数时，Azure DevOps 会基于此动态选择选择目标分支。

建议仅包含受拉取请求策略保护的分支，以确保提示提交的第一个父历史记录中的一致性。

在 Markdown 文件预览中支持美人鱼图

包含美人鱼语法的 Markdown 文件现在将在存储库文件浏览器和拉取请求的文件预览中呈现为关系图。 这有助于将更丰富的文档添加到存储库。

Azure Pipelines

Azure Pipelines 托管代理上的 Ubuntu 24.04

Ubuntu 24.04 映像现在可用于 Azure Pipelines 托管代理。 若要使用此映像，请更新 YAML 文件以包括 vmImage:'ubuntu-24.04'：

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d

注意

图像 ubuntu-latest 标签将继续指向 ubuntu-22.04，直到今年晚些时候。

有关已安装的软件，请参阅 Ubuntu 24.04 映像自述文件。

在 Azure 集成测试中使用工作负荷标识联合身份验证

今年6月，Azure 标识库 for.NET、C++、Go、Java、JavaScript 和 Python 添加了对工作负荷标识联合的支持。 这增加了从AzureCLI@2和AzurePowerShell@5任务执行的代码使用类进行身份验证的功能，Microsoft Entra（例如，访问 Azure）。AzurePipelinesCredential

许多客户都在从其他任务调用的集成测试中使用 Azure 标识库。 现在，我们添加了对AzurePipelinesCredentialDotNetCoreCLI@2、Maven@4和VSTest@3任务的支持。

可以将该 connectedService 属性设置为配置了工作负荷标识联合身份验证的 Azure 服务连接。 SYSTEM_ACCESSTOKEN需要AzurePipelinesCredential设置。

- task: DotNetCoreCLI@2
  inputs:
    command: 'run'
    connectedService: <Azure service connection configured with workload identity federation>
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

有关详细信息 AzurePipelinesCredential，请参阅此 博客文章。

通过改进的托管标识支持创建新的 Azure 服务连接体验

新的 Azure 服务连接创建体验提高了灵活性和安全默认值。 所用术语与 Microsoft Entra ID 一致，以便创建 Microsoft Entra ID 对象的用户在不同门户之间切换时时更容易理解。

创建新的 Azure 资源管理器服务连接时，现在可在单个统一对话框中使用各种配置标识的选项，用于替换之前使用的不同顶级项：

标识类型 列出了 Azure 服务连接支持的所有身份验证方案：

对于应用注册，可以独立选择 凭据 作为 工作负荷标识联合 或机密。

Azure 服务连接托管标识支持

现在可以选择预先存在的托管标识，并使用它来配置使用工作负荷标识联合的服务连接。 首先， 创建用户分配的托管标识。

然后，创建 Azure 服务连接并选择 托管标识 类型。 这会在托管标识上配置联合标识凭据。

使用分配给代理（池）的托管标识的选项已重命名为托管标识（代理分配）。 为了防止共享超特权托管标识，建议使用具有工作负荷标识联合的托管标识，而不是分配给代理池的托管标识。

如果 Microsoft Entra ID 中禁用，则托管标识也是无法创建应用注册的用户的建议选项。

若要将托管标识与工作负荷标识联合一起使用，请先选择包含托管标识的订阅和资源组。 这不同于管道作业中服务连接访问的订阅。 选择为工作负荷标识联合配置的托管标识。 用户需要 托管标识参与者 角色或托管标识的等效权限才能在托管标识上创建联合标识凭据。

继续选择将用作服务连接的部署范围的订阅。

“服务管理参考”字段

某些组织要求 使用 ITSM 数据库中的相关上下文信息填充应用注册的服务管理参考 。 如有必要，用户可以在创建服务连接时指定此引用。

详细信息

新的 Azure 服务连接创建体验在下个月推出。 有关详细信息，请参阅：

• Azure 服务连接文档
• 工作负荷联合身份验证
• 故障排除

父阶段失败时运行子阶段

使用 Azure Pipelines 可以更轻松地继续部署。 例如，使用 Pipelines 跨多个 Azure 区域部署应用程序的新版本时，这非常有用。

假设需要部署到连续五个 Azure 区域。 假设管道具有每个区域的阶段，每个阶段都有一个运行 AzureResourceManagerTemplateDeployment 任务的作业，然后记录一些遥测数据。 后者是好的，但不是关键。 假设记录遥测数据时出现问题。 现在，阶段会失败，部署停止。

从此冲刺开始，当阶段失败时，可以恢复运行其子阶段。

Azure Artifacts

使用公共源和 Cargo 向 Azure Artifacts 进行身份验证

由于 Cargo 客户端存在限制，身份验证是全能或全无的。 对于专用源，将发送身份验证，但对于 公共源（需要允许匿名用户），即使身份验证可用或需要，也不会发送任何身份验证。

现在，经过身份验证的用户可以连接到公共 Azure Artifacts 源，就像它们是专用源一样。 如果你或管道代理有权 保存来自上游源的包，则可以通过源从 crates.io 访问包。 此更改可控制哪些包可以回到源管理员手中。 将包从上游源引入源后，匿名用户将有权访问它们。

若要确保身份验证，请追加 ~force-auth 到注册表 URL 中的源名称。 可以通过我们的公共文档了解更多详细信息。

Wiki

改进将基于 HTML 的内容粘贴到 Wiki

我们已更轻松地将基于 HTML 的内容粘贴到 Wiki 中。 现在，链接、列表、表、图像、Excel 工作表、Microsoft Teams 消息、电子邮件和 Azure 数据资源管理器查询等 HTML 元素会自动转换为 Markdown 语法，以便更流畅地进行编辑。

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

你还可以在 Stack Overflow 上获得社区的建议和问题的答案。

此致

Dan Hellem