了解管道阶段

  • 7 分钟

使用 Pipelines 可以自动化部署过程中的步骤。 该过程可能包含要运行的作业的多个逻辑组。 在本单元中，你将了解管道阶段以及如何使用它们向 Bicep 部署添加质量控制过程。

什么是管道阶段？

阶段有助于将管道划分为多个逻辑块。 每个阶段可以包含一个或多个作业。 作业包含应完成的步骤的有序列表，例如运行命令行脚本。

Diagram that shows a pipeline with a stage containing one job. The job contains four steps.

可以在管道中使用阶段来标记分离关注点。 例如，使用 Bicep 代码时，验证代码与部署 Bicep 文件是单独的关注点。 使用自动化管道时，生成和测试代码的过程通常称为持续集成 (CI)。 在自动化管道中部署代码通常称为持续部署 (CD)。

在 CI 阶段，将检查对代码所做更改的有效性。 CI 阶段提供质量保证。 它们可在不影响实时生产环境的情况下运行。

在许多编程语言中，需要先生成代码，然后才能运行代码。 部署 Bicep 文件后，该文件会从 Bicep 转换或转译为 JSON。 工具会自动执行此过程。 在大多数情况下，无需手动将 Bicep 代码生成到管道中的 JSON 模板。 但当谈论 Bicep 代码时，我们仍使用术语“持续集成”，因为 CI 的其他部分仍然适用，例如验证代码。

CI 阶段成功运行后，你应更加确信你所做的更改也将成功部署。 在 CD 阶段，将代码部署到每个环境。 通常从测试和其他非生产环境开始，然后转到生产环境。 在本模块中，我们将部署到单个环境。 在后面的模块中，你将了解如何扩展部署管道以部署到多个环境，例如非生产环境和生产环境。

阶段按顺序运行。 可以控制每个阶段的运行方式和时间。 例如，可以将 CD 阶段配置为仅在 CI 阶段成功运行后运行。 或者，可以包含多个需要按顺序运行的 CI 阶段，例如先生成代码然后对其进行测试。 还可以包含一个回退阶段，该阶段仅在之前的部署阶段失败时运行。

左移

通过使用阶段，可以在部署代码之前验证代码的质量。 这些阶段有时称为“左移”。

细想一下在编写代码时执行活动的时间线。 时间线从规划和设计阶段开始。 然后，它进入“生成”和“测试”阶段。 最后，你进行部署，然后必须支持你的解决方案。

Chart with a timeline on the horizontal axis, cost on the vertical axis, and a line showing that the cost increases the later an error is identified.

软件开发中的一条浅显易懂的规则是，在开发过程中越早发现错误（越靠近时间线的左侧），修复起来就越容易、越快、越便宜。 在流程中发现错误的时间越晚，修复起来就越困难。

因此，目标是将问题的发现时间向上图的左侧移动。 在本模块中，你将了解如何在管道进行过程中向其添加更多验证和测试。

甚至可以在部署开始之前添加验证。 使用 Azure DevOps 等工具时，拉取请求通常代表团队中的某人想要对主分支上的代码所做的更改。 可以创建另一个管道，使其在拉取请求评审过程中自动运行 CI 步骤。 这种方法有助于验证即使进行了建议的更改，代码是否仍然有效。 如果验证成功，那么当你将更改合并到主分支时，你就会更加确信此操作不会引起问题。 如果检查失败，则表示拉取请求尚未准备就绪，无法进行合并。

重要

自动化验证和测试与编写的测试一样有效。 你要考虑需要测试的内容和需要执行的步骤，以确保部署正常，这一点很重要。

定义管道阶段

每个管道至少包含一个阶段。 如果管道只有一个阶段，则无需显式定义它。 Azure Pipelines 会自动进行定义。 如果管道中有多个阶段，则需要定义每个阶段。 阶段按指定的序列运行。

假设你生成了一个需要部署两次的 Bicep 文件：一次是部署到美国的基础结构，另一次是部署到欧洲的基础结构。 在部署之前，需要验证 Bicep 代码。 下面是定义此过程的多阶段管道的插图：

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, running in sequence.

请注意，此示例有 3 个阶段。 “验证”阶段类似于 CI 阶段。 然后，会运行“DeployUS”和“DeployEurope”阶段。 每个作业都将代码部署到其中一个环境中。

以下是如何在管道 YAML 文件中定义这些阶段的方式：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

控制阶段的顺序

默认情况下，阶段按定义的顺序运行。 仅当上一阶段运行成功后，才会运行当前阶段。 可在阶段之间添加依赖项以更改顺序。

继续上面的示例，假设你想要并行运行两个部署，如下所示：

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, with the two deployment stages running in parallel.

可以使用 dependsOn 关键字指定阶段之间的依赖关系：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

使用 dependsOn 关键字时，Azure Pipelines 会等待依赖阶段成功完成，然后再开始下一阶段。 如果 Azure Pipelines 检测到多个阶段的所有依赖项都已满足，则可并行运行这些阶段。

注意

实际上，仅当有足够的代理可以同时运行多个作业时，阶段和作业才能并行运行。 使用 Microsoft 托管代理时，可能需要购买额外的并行作业来实现此目的。

有时，你想要在上一阶段失败的情况下运行某个阶段。 例如，下面是一个不同的管道。 如果部署失败，则随后会立即运行名为“回退”的阶段：

Diagram that shows a pipeline with a Deploy stage, and a condition so that a failure in the Deploy stage results in the Rollback stage running.

可使用 condition 关键字指定在某阶段运行之前应满足的条件：

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

在上一示例中，如果一切顺利，Azure Pipelines 首先运行“验证”阶段，然后运行“部署”阶段。 它会跳过“回退”阶段。 但是，如果“部署”阶段失败，Azure Pipelines 将运行“回退”阶段。 本模块稍后会详细介绍回退。

每个作业都在新代理上执行。 这意味着每个作业都将从干净的环境开始，因此在每项作业中，通常需要先签出源代码。

Bicep 部署阶段

典型的 Bicep 部署管道包含多个阶段。 随着管道运行各个阶段，目标是越来越相信后期阶段会成功。 下面是 Bicep 部署管道的常见阶段：

Diagram that shows a Bicep deployment pipeline with five stages: Lint, Validate, Preview, Deploy, and Smoke Test.

  1. Lint 分析：使用 Bicep Linter 验证 Bicep 文件格式是否正确并且不包含任何明显的错误。
  2. 验证：使用 Azure 资源管理器预检验证过程检查部署时可能会发生的问题。
  3. 预览：使用 What-if 命令验证将应用于 Azure 环境的更改列表。 要求人工手动审阅 What-if 结果并批准管道继续运行。
  4. 部署：将部署提交到资源管理器并等待部署完成。
  5. 冒烟测试：对已部署的一些重要资源运行基本的部署后检查。 这些评审称为“基础结构冒烟测试”。

你的组织可能具有不同的阶段序列，或者可能需要将 Bicep 部署集成到部署其他组件的管道中。 了解了这些阶段的工作原理后，可以设计一个管道来满足你的需求。

在本模块中，你将了解此处所列阶段的详细信息，并逐步生成包含每个阶段的管道。 你还将了解：

  • 如果在之前的任何阶段中发生任何意外情况，管道如何停止部署过程。
  • 如何配置管道，使其在你手动验证上一阶段中发生的情况之前都暂停。