通过

定义审批和检查

  • 项目

Azure DevOps Services

管道是由阶段组成的。 管道作者可以通过定义阶段上的条件来控制阶段是否应运行。 控制阶段是否应运行以及何时运行的另一种方法是通过审批和检查。

yaml 文件中不会定义审批和其他检查。 修改管道 yaml 文件的用户无法修改在阶段开始前执行的检查。 资源的管理员使用 Azure Pipelines 的 Web 界面管理检查。

管道依赖于环境、服务连接、代理池、变量组和安全文件等资源。 检查使资源所有者能够控制任何管道中的阶段是否以及何时可以使用资源。 作为资源的所有者，你可以定义在使用该资源的阶段可以启动之前必须满足的检查。 例如，对某个环境进行手动审批检查可确保仅当指定用户查看要部署的更改之后才会部署到该环境。

一个阶段可以包含多个作业，每个作业可以消耗多个资源。 在开始执行阶段之前，必须满足该阶段中使用的所有资源的所有检查。 Azure Pipelines 在每个阶段之前暂停管道的执行，并等待所有挂起的检查完成。

有五类审批和检查，它们按在每个类别中创建的顺序运行。 检查将根据每个检查中指定的重试间隔重新计算。 如果所有检查在指定的“超时”之前都未成功，则不执行该阶段。 如果任何检查最终失败（例如，你拒绝了其中一个资源的审批），则不会执行该阶段。

可以在审批和检查超时时重试阶段。

静态检查先运行，然后运行预检查审批。 类别按顺序依次为：

  1. 静态检查：分支控件、必需模板和评估项目
  2. 预检查审批
  3. 动态检查：审批、调用 Azure 函数、调用 REST API、工作时间、查询 Azure Monitor 警报
  4. 检查后审批
  5. 排他锁

还可以在“审批和检查”选项卡上查看执行顺序。

重要

可以在环境、服务连接、存储库、变量组、安全文件和代理池上配置检查。

无法通过变量指定服务连接。

审批

可以使用审批和检查手动控制阶段应何时运行。 该检查通常用于控制向生产环境进行的部署。

  1. 登录到 Azure DevOps 组织，并导航到你的项目。

  2. 选择“管道”>“环境”，然后选择环境。

  3. 选择“审批和检查”选项卡，然后选择 + 符号，添加新检查。

    显示如何在 Azure Pipelines 中添加审批和检查的屏幕截图。

  4. 选择“审批”，然后选择“下一步”。

  5. 将用户或组添加为指定的“审批者”，如果需要，请为审批者提供说明。 指定是否允许或限制审批者批准自己的运行，并指定所需的“超时”。 如果审批未在指定的超时内完成，则阶段将标记为跳过。

  6. 完成操作后，选择“创建”。

    显示如何创建新审批的屏幕截图。

  7. 触发审批检查后，用户界面中会显示提示窗口，如以下示例所示。 此窗口为审批者提供拒绝或批准运行的选项以及相关的说明。

    显示审批提示窗口的屏幕截图。

审批和检查开始运行时修复了可以查看审批的用户的列表。 也就是说，不会选取检查开始执行后完成审批检查的用户和组列表的更改。

注意

如果将组指定为审批者，则只要组中一个用户批准，运行就能继续。

延迟审批

在某些情况下，给定审批的时间和部署开始的时间不匹配。 例如，你可能希望等待部署新版本，直到晚上的低流量时间。

若要解决这种情况，可以延迟审批，并设置审批生效的时间。

  1. 选择“延迟审批”。

    响应审批请求时延迟审批选项的屏幕截图。

  2. 设置审批时间。

    设置审批时间的屏幕截图。

你将在“检查”面板中看到预审批形式的审批。 审批将在设定的时间生效。

分支控制

使用分支控制检查，可以确保与管道相链接的所有资源都是从允许的分支生成的，并且分支已启用保护。 此检查有助于控制部署的发布准备和质量。 如果多个资源与管道链接，则会验证所有资源的源。 如果已链接另一个管道，则会验证所部署的特定运行的分支是否受到保护。

定义分支控制检查：

  1. 在 Azure DevOps 项目中，转到需要保护的资源（例如，环境）。

  2. 导航到资源对应的审批和检查。

  3. 选择分支控制检查并提供逗号分隔的允许分支列表。 可以强制分支启用保护。 如果其中一个分支的保护状态未知，还可以定义检查的行为。 如果至少应用了一个策略（包括存储库级别应用的策略），则分支被视为受保护。

    配置分支控制检查。

在运行时，检查将针对允许列表验证运行中所有链接资源的分支。 如果任何分支与条件不匹配，则检查失败，阶段标记为失败。

注意

检查要求分支使用完全限定的名称。 确保分支名称的格式为 refs/heads/<branch name>

营业时间

如果希望环境中的所有部署仅在特定的时间范围内进行，则工作时间检查是理想的解决方案。 运行管道时，使用资源的阶段将等到工作时间才会执行。 如果同时执行多个运行，则每个运行都经过独立验证。 在工作时间开始时，所有运行的检查将标记为成功。

配置工作时间检查。

如果阶段执行在工作时间结束时还未开始（因为某个其他检查而被耽搁），则工作时间审批会自动撤销，并安排在次日重新计算。 如果阶段的执行未在指定的检查超时期限内开始，并且阶段标记为失败，则检查失败。

调用 Azure 函数

Azure 函数是 Azure 提供的无服务器计算平台。 Azure 函数使你可以运行小段代码（称为“函数”），而不必考虑应用程序基础结构。 Azure 函数具有高度灵活性，提供了一种供你自行创作检查的好方法。 你可以包括签入 Azure 函数的逻辑，以便每次执行都是在 http 请求时触发的，执行时间较短，并会返回响应。 定义检查时，可以分析响应正文以推断检查是否成功。 可以使用控制选项中的“计算间隔时间”设置定期重复计算。 了解详细信息

配置 Azure 函数检查。

如果在配置的“超时”内检查未成功，则会跳过关联的阶段。 还会跳过依赖于它的阶段。 有关详细信息，请参阅 Azure Function App 任务。

注意

从 Sprint 215 开始，检查可以访问用户定义的管道变量。

详细了解使用“调用 Azure 函数”检查的建议方法。 检查需要遵循特定规则，具体取决于其模式和要符合的重试次数。

调用 REST API

调用 REST API 检查使你能够与任何现有服务集成。 定期调用 REST API 并在返回成功响应后继续。 了解详细信息

可以使用控制选项中的计算间隔时间设置定期重复计算。 如果在配置的“超时”内检查未成功，则会跳过关联的阶段。 还会跳过依赖于它的阶段。 有关详细信息，请参阅调用 REST API 任务。

注意

从 Sprint 215 开始，检查可以访问用户定义的管道变量。

详细了解使用“调用 REST API 函数”检查的建议方法。

查询 Azure Monitor 警报

Azure Monitor 对来自单个 Azure 基础结构和每个单独的 Azure 资源的数据提供可视化效果、查询、路由、警报、自动缩放和自动化功能。 警报是检测基础结构或应用程序健康状况问题并采取纠正措施的标准方法。 Canary 部署和分阶段推出是用于降低关键应用程序回归风险的常见部署策略。 部署到阶段（一组客户）阶段后，将观察应用程序一段时间。 部署后应用程序的健康状况用于确定是否应在下一阶段进行更新。

查询 Azure Monitor 警报有助于观察 Azure Monitor，并确保部署后不会针对应用程序引发警报。 如果在评估时未激活任何警报规则，则检查成功。 了解详细信息

在控制选项中的计算间隔时间设置之后重复计算。 如果阶段未在指定的超时期限内开始执行，则检查将失败。

所需模板

借助所需的模板检查，可以强制管道使用特定的 YAML 模板。 实施此检查后，如果管道不从引用的模板扩展，管道将失败。

定义所需的模板审批：

  1. 在 Azure DevOps 项目中，转到要限制的服务连接。

  2. 打开编辑旁边的菜单中的审批和检查。

  3. 在添加第一个检查菜单中，选择所需模板。

  4. 输入有关如何访问所需模板文件的详细信息。

    • 存储库类型：存储库的位置（GitHub、Azure 或 Bitbucket）。
    • 存储库：包含模板的存储库的名称。
    • 引用：所需模板的分支或标记。
    • 所需模板的路径：模板的名称。

同一服务连接可以有多个所需模板。 在此示例中，所需模板为 production_template.yaml。

配置所需模板检查。

禁用检查

调试检查时，可能需要先暂时禁用检查，然后重新启用检查。 若要禁用或启用检查，请：

  1. 在 Azure DevOps 项目中，使用检查转到资源。

  2. 打开“审批和检查”选项卡。

  3. 在上下文菜单中，选择“禁用”或“启用”。

    禁用检查选项的屏幕截图。

绕过检查

在某些情况下（例如修补程序部署），可能需要绕过检查。 仅当对规定检查的资源具有管理员权限时，才能绕过检查。

若要绕过审批、营业时间、调用 Azure 函数或调用 REST API 检查，请在资源等待评审时选择“绕过检查”。 下面是绕过营业时间检查的示例。

绕过工作时间检查选项的屏幕截图。

绕过检查时，可以在“检查”面板中看到谁绕过了检查。

已绕过检查的日志的屏幕截图。

评估工件

可以根据自定义策略评估要部署到环境中的工件。

注意

目前，这仅适用于容器映像工件

要定义对工件的自定义策略评估，请执行以下步骤。

  1. 在 Azure DevOps Services 项目中，转到需要保护的环境。 详细了解如何创建环境。

    查看环境。

  2. 导航到资源对应的“审批和检查”。

    向环境添加检查。

  3. 选择“评估工件”。

    添加评估工件检查。

  4. 粘贴策略定义，然后选择“保存”。 详细了解如何编写策略定义。

    添加策略定义。

运行管道时，该运行的执行会在进入使用环境的阶段之前暂停。 根据可用的映像元数据评估指定的策略。 策略成功时通过检查，否则检查失败。 如果检查失败，阶段标记为失败。

查看通过的检查。

还可以从管道视图查看策略检查的完整日志。

查看通过的检查日志。

排他锁

排他锁检查仅允许从管道进行一次运行，并且可以在阶段或管道级别进行设置。 该管道的所有运行中使用该资源的所有阶段都会暂停。 当使用锁的阶段完成时，另一个阶段可以继续使用资源。 此外，只允许一个阶段继续。

lockBehavior 属性确定其他阶段如何处理锁。 为阶段指定 lockBehavior 属性时，会自动为该阶段创建锁。 有两个可能的 lockBehavior 值：

  • runLatest - 只有最新的运行获取资源的锁。 如果未指定 lockBehavior，则 runLatest 是默认值。
  • sequential - 所有运行都按顺序获取受保护资源的锁。

若要将排他锁检查用于 sequential 部署或 runLatest，请执行以下步骤：

  1. 在环境（或其他受保护资源）上启用排他锁检查。 排他锁选项是可用的检查。

    排他锁选项“审批”选项卡的屏幕截图。

  2. 在管道的 YAML 文件中，指定名为 lockBehavior 的属性。 可以针对整个管道或给定的阶段指定此属性：

在阶段上设置：

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

在管道上设置：

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

如果未指定 lockBehavior 并且对资源设置了锁，则使用默认值 runLatest。

排他锁检查只允许从管道进行一次运行。 该管道的所有运行中使用该资源的所有阶段都会暂停。 当使用锁的阶段完成时，另一个阶段可以继续使用资源。 此外，只允许一个阶段继续。 尝试获取锁的任何其他阶段都将被取消。

ServiceNow 变更管理

此检查需要从市场安装 ServiceNow 变更管理扩展

ServiceNow 变更管理检查允许在管道中集成 ServiceNow 变更管理过程。 通过添加检查，可以在阶段开始时在 ServiceNow 中自动创建新变更请求。 管道在开始阶段之前等待变更过程完成。 此处提供了更多详细信息。

多个审批和检查

一个阶段可以包含多个作业，每个作业可以消耗多个资源。 在开始执行阶段之前，必须满足该阶段中使用的所有资源的所有检查。 Azure Pipelines 在每个阶段之前暂停管道的执行，并等待所有挂起的检查完成。

单个最终否定决策会导致管道访问被拒绝，阶段失败。 所有审批和检查（调用 Azure 函数/REST API 和排他锁除外）都是最终决定。 可以重新运行成功的“调用 Azure 函数/REST API”检查。

以建议的方式使用“调用 Azure 函数/REST API”检查时，其访问决策也是最终决定。

将“调用 Azure 函数/REST API”检查的“评估间隔时间”指定为非零值时，检查的决定不是最终决定。 此方案值得继续探索。

我们来看一个示例。 假设 YAML 管道有一个使用服务连接的阶段。 此服务连接配置有两个检查：

  1. 名为授权外部审批的异步检查，用于验证是否已授予外部审批，并按建议方式配置。
  2. 名为部署原因有效的同步检查，用于验证部署原因是否有效，并为其将评估间隔时间设置为 7 分钟。

下图显示了可能的检查执行。 显示异步和同步检查执行时间线的图表。

在此执行中：

  • 同时调用授权外部审批和部署原因有效两个检查。 部署原因有效会立即失败，但由于授权外部审批处于挂起状态，因此将重试。
  • 在第 7 分钟，将重试部署原因有效，这一次会通过检查。
  • 在第 15 分钟，授权外部审批调用回 Azure Pipelines 并返回成功决定。 现在，两个检查都已通过，因此允许管道继续部署阶段。

让我们看一下另一个涉及两个同步检查的示例。 假设 YAML 管道有一个使用服务连接的阶段。 此服务连接配置有两个检查：

  1. 名为同步检查 1 的同步检查，其将评估间隔时间设置为 5 分钟。
  2. 名为同步检查 2 的同步检查，其将评估间隔时间设置为 7 分钟。

下图显示了可能的检查执行。 该图显示两个同步检查执行的时间线。

在此执行中：

  • 同时调用同步检查 1 和同步检查 2 这两个检查。 同步检查 1 通过，但会重试，因为同步检查 2 失败。
  • 在第 5 分钟，同步检查 1 已重试，但失败，因此还将重试。
  • 在第 7 分钟，同步检查 2 重试并成功。 通过决策的有效期为 7 分钟。 如果同步检查 1 未在此时间间隔内通过，同步检查 2 将重试。
  • 在第 10 分钟，同步检查 1 已重试，但失败，因此还将重试。
  • 在第 14 分钟，同步检查 2 重试并成功。 通过决策的有效期为 7 分钟。 如果同步检查 1 未在此时间间隔内通过，同步检查 2 将重试。
  • 在第 15 分钟，同步检查 1 重试并成功。 现在，两个检查都已通过，因此允许管道继续部署阶段。

让我们看一个涉及审批和同步检查的示例。 假设你为服务连接配置了同步检查和审批，“评估间隔时间”为 5 分钟。 在获得批准之前，无论做出何种决定，检查都将每 5 分钟运行一次。

常见问题解答

定义的检查未开始。 发生了什么情况？

检查评估将在满足阶段条件后开始。 应确认在对资源添加检查后已开始运行阶段，并且在阶段中已使用资源。

如何利用检查来计划阶段？

使用工作时间检查，可以控制阶段执行开始的时间。 可以在设计器发布中实现与阶段预定义计划相同的行为。

如何对计划将来运行的阶段使用预先批准？

可以启用该方案。

  1. 工作时间检查允许将部署到某个资源的所有阶段计划在某个时间窗口中执行
  2. 在同一资源上配置审批时，阶段将等待审批，然后才会启动。
  3. 可以在资源上配置这两个检查。 阶段将等待审批和工作时间。 审批完成后，它将在下一个计划时段开始。

是否可以等待对正在部署的工件完成安全扫描？

要等待对正在部署的工件完成安全扫描，需要使用外部扫描服务，例如 AquaScan。 在开始检查之前，需要将部署的工件上传到扫描服务可访问的位置，并且可以使用预定义变量进行标识。 使用“调用 REST API”检查，可以添加检查以在安全服务中等待 API，并将工件标识符作为输入传递。

如何在检查中使用前面阶段的输出变量？

默认情况下，只有预定义的变量可用于检查。 可以使用链接的变量组来访问其他变量。 前一阶段的输出变量可以写入变量组，并在检查中进行访问。

了解详细信息