添加阶段、依赖项和条件

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

阶段是指 Azure DevOps 管道中的逻辑边界。 阶段可用于对软件开发流程中的操作进行分组（例如，生成应用、运行测试、部署到预生产环境）。 每个阶段可以包含一个或多个作业。

在管道中定义多个阶段时，默认情况下，它们将依次运行。 阶段也可相互依赖。 可使用 dependsOn 关键字来定义依赖项。 此外，阶段还可根据附带条件的上一阶段的结果来运行。

若要了解阶段如何处理并行作业和许可，请参阅配置并行作业并为其付费。

若要了解阶段与管道的其他部分（如作业）的关系，请参阅关键管道概念。

还可以在 YAML 架构阶段一文中详细了解阶段与管道的各个部分的关系。

YAML

可以将管道作业组织到阶段。 阶段是管道中的主要分支：阶段的典型示例包括“生成此应用”、“运行这些测试”和“部署到预生产环境”。 它们是管道中的逻辑边界，你可在其中暂停管道并执行各种检查。

每个管道至少有一个阶段，即使你未显式定义它，也是如此。 还可以将阶段排列到依赖项关系图中，以便一个阶段先于另一个阶段运行。 一个阶段的作业限制为 256 个。

经典

在发布管道中将部署作业组织到阶段。 阶段是发布管道中的主要分支：发布阶段的典型示例包括“运行功能测试”、“部署到预生产环境”和“部署到生产环境”。

发布管道中的阶段由作业和任务组成。

审批和入口、部署条件和触发器以及队列策略控制发布何时部署到阶段。

指定阶段

YAML

在最简单的情况下，管道中不需要任何逻辑边界。 在这种情况下，无需显式使用 stage 关键字。 可以直接在 YAML 文件中指定作业。

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

如果要将管道组织到多个阶段中，请使用 stages 关键字。

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

如果选择在阶段级别指定 pool，则该阶段中定义的所有作业均会使用该池，除非在作业级别进行指定。

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

用于指定阶段的完整语法为：

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

经典

若要向发布管道添加阶段，请在发布页中选择发布管道，选择用于编辑该管道的编辑操作，然后选择管道选项卡。虽然定义阶段的最重要部分是自动化任务，但还可以在发布管道中为阶段配置多个属性和选项。 方法：

• 在此处编辑阶段的名称（如有必要）。
• 将一个用户或组指定为阶段所有者。 每当部署到该阶段失败时，阶段所有者会收到通知。 成为阶段所有者不会自动具有任何权限。
• 从管道中删除阶段。
• 更改阶段的顺序。
• 将阶段的副本另存为阶段模板。
• 管理阶段的安全设置。

指定依赖项

YAML

在管道中定义多个阶段时，默认情况下，它们按照自己在 YAML 文件中的定义顺序依次运行。 添加依赖项时除外。 对于依赖项，阶段按 dependsOn 要求的顺序运行。

管道必须包含至少一个没有依赖项的阶段。

用于定义多个阶段及其依赖项的语法为：

stages:
- stage: string
  dependsOn: string
  condition: string

按顺序运行的示例阶段：

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

并行运行的示例阶段：

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

扇出和扇入的示例：

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

经典

可以通过在发布管道的每个阶段上设置触发器来控制依赖项：

• 阶段通过触发器或手动启动运行。
• 借助发布后触发器，一个阶段会在发布开始后立即启动，并与具有发布后触发器的其他阶段并行运行。
• 使用阶段后触发器时，阶段将在所有依赖阶段完成后启动。 利用这一点，可以为阶段的扇出和扇入行为建模。

定义条件

可以使用表达式指定每个阶段运行的条件。 默认情况下，如果一个阶段不依赖于任何其他阶段，或者它所依赖的所有阶段都已完成且成功，它就会运行。 可以通过强制阶段运行（即使先前的阶段失败）或通过指定自定义条件来自定义此行为。

如果为某个阶段自定义前面步骤的默认条件，则会删除完成和成功的条件。 因此，如果使用自定义条件，通常会使用 and(succeeded(),custom_condition) 来检查前面的阶段是否成功运行。 否则，无论前面阶段的结果如何，阶段都会运行。

注意

以下示例所示的 failed('JOBNAME/STAGENAME') 和 succeeded('JOBNAME/STAGENAME') 的条件仅适用于 YAML 管道。

YAML

基于运行前面阶段的状态运行阶段的示例：

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

使用自定义条件的示例：

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

经典

指定发布后或阶段后触发器时，还可以为发布中使用的工件指定分支筛选器。 仅当满足分支筛选器时，发布才会部署到阶段。

指定队列策略

YAML

YAML 管道不支持队列策略。 管道的每个运行都独立于其他运行，并且不知道其他运行。 换句话说，你的两个连续提交可能会触发两个管道，并且它们都将执行相同的阶段序列，而无需相互等待。 虽然我们努力将队列策略引入 YAML 管道，但我们建议你使用手动审批，以便手动排序和控制执行顺序（如果这很重要）。

经典

在某些情况下，你产生生成的速度可能比其部署速度更快。 或者，你可能会配置多个代理，并且从同一发布管道创建发布来部署不同的工件，等等。 在这种情况下，能够控制多个发布如何排队进入阶段会很有用。 队列策略可让你进行这种控制。

可以为队列策略选择的选项包括：

• 并行部署数量：如果在阶段中动态预配新资源，并且该阶段实际上能够并行处理多个版本的部署，但你想要限制并行部署的数量，请使用此选项。

• 如果指定最大部署数，则会显示另外两个选项：

  • 全部按顺序部署：如果要按顺序将所有发布部署到同一共享物理资源，请使用此选项。 通过一个接一个地依次部署生成，可以确保两个部署作业不会同时以相同的物理资源为目标，即使有多个生成和发布代理可用也是如此。 此外，还应确保按顺序发送此阶段的部署前审批请求。

  • 部署最新版本，取消其他版本：如果产生版本的速度比产生版本快，并且你只想部署最新生成，请使用此选项。

若要了解这些选项的工作原理，请考虑一个场景，其中单个发布管道的发布 R1、R2、......、R5 会快速连续创建。 假设此管道中的第一阶段名为 QA，且定义了部署前与部署后审批者。

• 如果没有为并行部署数指定限制，则在创建版本后会立即发出全部五个审批请求。 如果审批者批准所有发布，它们将并行部署到 QA 阶段。 （如果 QA 阶段未定义任何部署前审批者，则全部五个版本均会自动并行部署到此阶段）。

• 如果指定了限制并按顺序进行部署所有版本且已达到限制，则会先发出版本 R1 的部署前审批。 完成此审批后，会开始将发布 R1 部署到 QA 阶段。 接下来，将针对发布 R1 发送后期部署审批请求。 仅当完成此部署后审批之后，才会开始执行版本 R2 并发出其部署前审批。而对于所有版本，该流程均会依次按此方式继续执行。

• 如果指定了限制且部署最新版本并取消其他版本且已达到限制，则会跳过版本 R2、R3 和 R4；同时，在版本 R1 的部署后审批完成后，会立即发出 QA 阶段中 R5 的部署前审批。

指定审批

YAML

可以使用审批检查手动控制阶段应何时运行。 这通常用于控制向生产环境进行的部署。 检查是资源所有者可用的一种机制，用于控制管道中的阶段是否以及何时可以使用资源。 作为资源（如环境）的所有者，你可以定义在使用该资源的阶段可以启动之前必须满足的检查。

目前，环境支持手动审批检查。 有关详细信息，请参阅审批。

经典

可以在管道中每个阶段的开头或结尾处添加手动审批。 有关详细信息，请参阅发布审批和入口概述。