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

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

注意

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

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

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

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

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

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

YAML

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

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

注意

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

此版本的 TFS 不支持 YAML。

经典

可在发布管道中将部署作业组织到阶段。 阶段是发布管道中的主要部门：“运行功能测试”、“部署到预生产”和“部署到生产”是发布阶段的不错示例。

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

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

指定阶段

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 管道。

经典

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

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

指定依赖项

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 管道。

经典

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

• 阶段使用触发器或手动启动运行。
• 使用 After 发布 触发器时，阶段将在发布开始后立即启动，与具有 After 发布 触发器的其他阶段并行。
• 使用 After 阶段 触发器时，阶段将在所有依赖阶段完成后启动。 使用此模型，可以为阶段的扇出和扇入行为建模。

条件

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

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

注意

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

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

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

经典

在某些情况下，生成生成的速度可能比部署更快。 或者，可以配置多个 代理 ，例如，从同一发布管道创建发布，以便部署不同的项目。 在这种情况下，能够控制如何将多个版本排队到某个阶段非常有用。 队列策略 提供该控制权。

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

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

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

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

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

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

• 如果未指定并行部署的数量限制，则创建发布后，将立即发送所有五个审批请求。 如果审批者批准所有版本，它们将并行部署到 QA 阶段。 (如果 QA 阶段未定义任何预部署审批者，则所有五个版本将自动与此阶段并行部署) 。

• 如果指定限制并 按顺序部署所有，并且已达到限制，则将首先发送发布 R1 的预部署批准。 完成此审批后，开始将发布 R1 部署到 QA 阶段。 接下来，针对发布 R1 发送部署后审批请求。 只有在完成此部署后审批后，才会开始执行发布 R2 ，并发送其部署前审批。对于所有版本，此过程会像这样继续。

• 如果指定限制和部署最新，并取消其他限制，并且已达到限制，将跳过发布 R2、R3 和 R4，并在完成发布 R1 的部署后批准后立即发送 QA 阶段 R5 的预部署审批。

指定审批

YAML

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

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

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

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

经典

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