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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

注意

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

阶段的概念因使用 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 作业，则在该阶段中定义的所有作业都将使用该池，除非在作业级别另有指定。

注意

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

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

经典

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

• 阶段使用触发器或手动启动来运行。
• 使用 “发布后 ”触发器时，一个阶段将在发布启动后立即启动，与发布 后 触发器的其他阶段并行启动。
• 使用 “后”阶段 触发器时，一个阶段将在所有依赖阶段完成后开始。 使用此方法，可以针对阶段对扇出和扇入行为进行建模。

条件

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

如果为阶段自定义上述步骤的默认条件，请删除完成和成功的条件。 因此，如果使用自定义条件，通常用于 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，QA 阶段中的 R5 预部署审批将在发布 R1 完成后批准后立即发出。

指定审批

YAML

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

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

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

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

经典

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