增强的安全性和管道工作流

在这个迭代中，我们将通过提高安全可见性和简化管道工作流来增强 DevOps 工作流。 GitHub 高级安全性现在包括对 依赖项扫描、代码扫描以及 机密扫描的详细启用跟踪，从而更深入地了解组织的安全范围。

此外，我们很高兴引入以管道为中心的增强功能，包括新的 YAML 表达式函数和手动验证任务的扩展控件，使你能够创建更高效且更安全的工作流。

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

GitHub 为 Azure DevOps 提供的高级安全功能

• 特定工具的安全概览覆盖范围

Azure Boards：

• Azure Boards 与具有数据驻留功能的 GitHub Enterprise Cloud 的集成

Azure Repos

• Azure Repos 的稀疏签出
• 使跨存储库策略区分大小写

Azure Pipelines

• 新的管道表达式函数
• ManualValidation 任务的增强功能

测试计划

• Azure 测试计划 Bug 修复

GitHub 高级安全性用于 Azure DevOps

特定于工具的安全概览覆盖范围

GitHub Advanced Security for Azure DevOps 中的安全概述现在详细介绍了每个扫描工具的启用状态，包括 依赖项扫描、代码扫描，以及 机密扫描。 通过此增强功能，可以查看组织中所有存储库的精细启用状态。

有关更多信息，请参阅高级安全性的安全概览。

Azure Boards

Azure Boards 与具有数据驻留功能的 GitHub Enterprise Cloud 的集成（预览版）

Azure Boards 现在支持与已启用数据驻留的 GitHub Enterprise Cloud 组织集成。 此更新符合 GitHub 于 2024 年 9 月的公告，宣布为企业云客户引入数据驻留，首先从欧盟 (EU) 的客户开始。

要将 Azure Boards 项目连接到具有数据驻留的 GitHub Enterprise Cloud 组织，请执行以下步骤：

1. 在 Azure Boards 中创建新连接。

2. 选择具有数据驻留 选项的 GitHub Enterprise Cloud。

Azure Repos

Azure Repos 的稀疏签出

现在，YAML 签出任务中支持 git sparse-checkout 命令和 partial clone filter，以提高存储库签出性能。 可以使用属性 sparseCheckoutDirectories 和 sparseCheckoutPatterns。

设置 sparseCheckoutDirectories 启用圆锥模式，其中签出过程使用目录匹配。 或者，可以设置 sparseCheckoutPatterns 触发非圆锥模式，从而允许更复杂的模式匹配。

如果设置了这两个属性，代理会使用目录匹配初始化圆锥模式。 如果在签出任务中未指定这两个属性，则会禁用稀疏签出过程。 在命令执行过程中遇到的任何问题都会导致签出任务失败。

稀疏签出锥模式的 YAML 示例：

    checkout: repo
    sparseCheckoutDirectories: src

稀疏签出非锥模式的 YAML 示例：

   checkout: repo
   sparseCheckoutPatterns: /* !/img 

可以在发布页面上找到该代理。

使跨存储库策略区分大小写

以前，跨存储库策略中的分支候选预览会以不区分大小写的方式显示结果，尽管分支匹配是区分大小写的。 这种不一致带来了潜在的问题，因为某些分支看起来像是受到了保护，但实际上并没有。 为了解决这一问题，我们更新了分支模式预览，使其与策略应用程序区分大小写的行为保持一致。

以前：

之后：

Azure Pipelines

新的管道表达式函数

使用管道表达式函数可以编写功能强大的 YAML 管道。 在此冲刺中，我们引入了两个新函数：

• 当 condition 的计算结果为 true 或 value_when_false 时返回 value_when_true 的 iif(condition, value_when_true, value_when_false)，否则为

• trim(string) 返回一个新字符串，其中删除字符串开头和结尾的空格

例如，可以使用 iif 函数动态选择用于运行管道的池。 如果你想使用 Azure Pipelines 池构建拉取请求，但所有其他运行都应该使用托管的 DevOps 池，那么你可以编写以下管道。

variables:
  poolToUse: ${{ iif(eq(variables['Build.Reason'], 'PullRequest'), 'Azure Pipelines', 'ManagedDevOpsPool')}}

stages:
- stage: build
  pool: ${{variables.poolToUse}}
  jobs:
  - job:
    steps:   
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'

可以使用 trim 函数使 YAML 对用户输入更具弹性。 例如，在以下管道中，我们使用 trim 函数来确保阶段名称不以空格开头。

parameters:
- name: regions
  type: string
  default: '  wus1,   wus2, wus3,wus4'

stages:
- ${{ each region in split(parameters.regions, ',')}}:
  - stage: stage_${{trim(region)}}
    displayName: Deploy to ${{trim(region)}}
    jobs:
    - job: deploy
      steps:
      - script: ./deploy.sh ${{trim(region)}}

ManualValidation 任务的增强功能

ManualValidation 任务使你可以暂停管道运行并等待手动干预。 使用此任务的一种方案是手动测试。

若要提高管道的安全性，你可能希望限制谁可以完成任务并恢复管道运行。 为此，我们将引入任务的新版本，该版本提供两个附加参数：

• approvers：将谁可以完成任务限制为一组预定义的用户/安全组/团队

• allowApproversToApproveTheirOwnRuns：限制将管道运行排队的用户对其进行恢复

例如，以下 YAML 代码片段将可以恢复管道运行的人员集限制为发布审批者组的成员，但不受触发管道运行的用户的限制。

- task: ManualValidation@1
  inputs:
    notifyUsers: 'Release Approvers'
    approvers: 'Release Approvers'
    allowApproversToApproveTheirOwnRuns: false

在 approvers 属性中，可以使用以下值（逗号分隔）：

• 电子邮件地址，
• 权限组，
• 项目团队，
• [ProjectName][权限组]，
• [组织][权限组]，
• [ProjectName][项目团队]

测试计划

Azure 测试计划 Bug 修复

通过此冲刺，我们对 Azure 测试计划进行了更新，以解决多个 bug 并改进可用性。 以下是已修复的内容：

• 现在会显示共享步骤结果：修复了一个 bug，即在访问 New Boards Hub 中的测试用例时，共享步骤结果不会出现在查询编辑器中。

• 改进了利益干系人模式会话： 解决了测试和反馈扩展中的问题，该扩展阻止了具有利益干系人访问权限的用户启动会话。

• 更清洁的测试计划复制： 修复了使用“引用现有测试用例”选项复制测试计划时要求重复的问题。

后续步骤

请转到 Azure DevOps 并看看里面有什么。

如何提供反馈

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

你还可以在 Stack Overflow上向社区寻求建议并获得解答。

谢谢

Silviu Andrica