添加阶段、依赖项、 & 条件

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

注意

在 Microsoft Team Foundation Server (TFS) 2018 和更低版本中,生成和发布管道被称为“定义”,运行被称为“生成”,服务连接被称为“服务终结点”,阶段被称为“环境”,而作业被称为“阶段” 。

阶段是管道中的逻辑边界。 它可用于标记关注点 (例如生成、QA 和生产) 。 每个阶段包含一个或多个作业。 在管道中定义多个阶段时,默认情况下,它们一个接一个地运行。

对于经典管道,可以将发布管道中的部署作业组织成阶段。

若要了解阶段如何使用并行作业和许可,请参阅 配置并行作业并为其付费

若要了解阶段如何与管道的其他部分(如作业)相关,请参阅 关键管道概念

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

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

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

注意

Azure DevOps Server 2019.1 中添加了对阶段的支持。

此版本的 TFS 不支持 YAML。

指定阶段

注意

Azure DevOps Server 2019.1 中添加了对阶段的支持。

在最简单的情况下,管道中不需要任何逻辑边界。 在这种情况下,无需显式使用 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 则该阶段中定义的所有作业都将使用该池,除非在作业级别另行指定。

注意

在 2019 Azure DevOps Server中,只能在作业级别指定池。

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]

此版本的 TFS 不支持 YAML 管道。

指定依赖项

注意

Azure DevOps Server 2019.1 中添加了对阶段的支持。

在管道中定义多个阶段时,默认情况下,它们按在 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

此版本的 TFS 不支持 YAML 管道。

条件

可以指定使用 表达式运行每个阶段的条件。 默认情况下,如果阶段不依赖于任何其他阶段,或者它所依赖的所有阶段都已完成并成功,则阶段将运行。 可以通过强制运行阶段(即使上一阶段失败)或通过指定自定义条件来自定义此行为。

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

注意

失败 ('JOBNAME/STAGENAME') 和成功 ('JOBNAME/STAGENAME') 的条件,如以下示例所示,仅适用于 YAML 管道

注意

Azure DevOps Server 2019.1 中添加了对阶段的支持。

基于运行上一阶段的状态运行阶段的示例:

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'))

此版本的 TFS 不支持 YAML 管道。

指定队列策略

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

此版本的 TFS 不支持 YAML 管道。

指定审批

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

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

此版本的 Azure DevOps Server 的 YAML 管道尚不支持审批。

此版本的 TFS 不支持 YAML 管道。