了解工作流作业
使用工作流可以自动化部署过程中的步骤。 该过程可能包含要运行的作业的多个逻辑组。 在本单元中，你将了解工作流作业，以及如何使用它们向 Bicep 部署添加质量控制过程。
什么是工作流作业？
作业有助于将工作流划分为多个逻辑块。 每个作业可包含一个或多个步骤。
可以在工作流中使用作业来标记关注点的分离。 例如，使用 Bicep 代码时，验证代码与部署 Bicep 文件是单独的关注点。 使用自动化工作流时，生成和测试代码的过程通常称为“持续集成”(CI)。 在自动化工作流中的部署代码通常称为“持续部署”(CD)。
在 CI 作业中，你将检查对代码所做更改的有效性。 CI 作业提供质量保证。 它们可在不影响实时生产环境的情况下运行。
在许多编程语言中，需要先生成代码，然后才能运行代码。 部署 Bicep 文件后，该文件会从 Bicep 转换或转译为 JSON。 工具会自动执行此过程。 在大多数情况下，无需手动将 Bicep 代码生成到工作流中的 JSON 模板。 但当谈论 Bicep 代码时，我们仍使用术语“持续集成”，因为 CI 的其他部分仍然适用，例如验证代码。
CI 作业成功运行后，你将更加确信你所做的更改也会成功部署。 在 CD 作业中，将代码部署到每个环境。 通常从测试和其他非生产环境开始，然后转到生产环境。 在本模块中，我们将部署到单个环境。 在后面的模块中，你将了解如何扩展部署工作流以部署到多个环境，例如非生产环境和生产环境。
默认情况下，作业将并行运行。 你可以控制每个作业的运行方式和时间。 例如，可将你的 CD 作业配置为仅在 CI 作业成功运行后运行。 或者，可以包含多个需要按顺序运行的 CI 作业，例如先生成代码然后对其进行测试。 还可以包含一个回滚作业，该作业仅在之前的部署作业失败时运行。
左移
通过使用作业，可在部署代码之前验证代码的质量。 此过程这有时称为“左移”。
细想一下在编写代码时执行活动的时间线。 时间线从规划和设计阶段开始。 然后，它进入“生成”和“测试”阶段。 最后，你进行部署，然后必须支持你的解决方案。
软件开发中的一条浅显易懂的规则是，在开发过程中越早发现错误（越靠近时间线的左侧），修复起来就越容易、越快、越便宜。 在开发过程中发现错误的时间越晚，修复起来就越困难、越复杂。
因此，目标是将问题的发现时间向上图的左侧移动。 在本模块中，你将了解如何在工作流进行过程中向其添加更多验证和测试。
甚至可以在部署开始之前添加验证。 使用 GitHub 等工具时，拉取请求通常代表团队中的某人想要对主分支上的代码做出的更改。 创建另一个工作流也是有帮助的，它在拉取请求的评审过程中会自动运行 CI 步骤。 这种方法有助于验证即使进行了建议的更改，代码是否仍然有效。 如果验证成功，那么当你将更改合并到主分支时，你就会更加确信此操作不会引起问题。 如果检查失败，则表示拉取请求尚未准备就绪，无法进行合并。 在将来的模块中，你将详细了解如何使用拉取请求和分支策略设置正确的发布过程。
重要
自动化验证和测试与编写的测试一样有效。 你要考虑需要测试的内容和需要执行的步骤，以确保部署正常，这一点很重要。
定义工作流作业
每个工作流至少包含一个作业，可根据需要定义更多作业。 默认情况下，作业将并行运行。 你拥有的 GitHub 帐户的类型决定了在使用 GitHub 托管的运行程序时可同时运行的作业数。
假设你生成了一个需要部署两次的 Bicep 文件：一次是部署到美国的基础结构，另一次是部署到欧洲的基础结构。 还需要验证工作流中的 Bicep 代码。 下面是一个多作业工作流的说明，它定义了一个类似过程：
请注意，此示例有三个作业。 “验证”作业类似于 CI 作业。 然后运行“部署美国”和“部署欧洲”作业。 每个作业都将代码部署到其中一个环境中。 默认情况下，这些作业将并行运行。
下面是工作流 YAML 文件中定义作业的方式：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
控制作业顺序
可在作业之间添加依赖关系以更改顺序。 继续前面的示例，可能需要在运行部署作业之前验证代码，如下所示：
可使用 needs 关键字指定作业之间的依赖关系：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
使用 needs 关键字时，工作流将等待依赖作业成功完成，然后才能开始下一作业。 如果工作流检测到多个作业的所有依赖关系都已满足，则可并行运行这些作业。
注意
实际上，只有在有足够的运行程序同时运行多个作业时，作业才能并行运行。 可以使用的 GitHub 托管运行器的数量取决于所拥有的 GitHub 帐户的类型。 如需更多并行作业，可购买另一个 GitHub 帐户计划。
有时，你需要在上一个作业失败时运行作业。 例如，下面是一个不同的工作流。 如果部署失败，则随后会立即运行名为“回滚”的作业：
使用 if 关键字指定在作业运行前应满足的条件：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deploy:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy."
rollback:
runs-on: ubuntu-latest
needs: deploy
if: ${{ failure() }}
steps:
- run: echo "Here is where you'd perform the steps to roll back a failure."
在上一示例中，如果一切顺利，工作流将首先运行“测试”作业，然后运行“部署”作业。 它会跳过“回滚”作业。 但是，如果“测试”作业或“部署”作业失败，工作流将运行“回滚”作业。 本模块稍后会详细介绍回退。
Bicep 部署作业
典型的 Bicep 部署工作流包含多个作业。 随着工作流执行各个作业，目标是越来越相信后期作业会成功。 下面是 Bicep 部署工作流的常见作业：
- Lint 分析：使用 Bicep Linter 验证 Bicep 文件格式是否正确并且不包含任何明显的错误。
- 验证：使用 Azure 资源管理器预检验证过程检查部署时可能会发生的问题。
- 预览：使用 What-if 命令验证将应用于 Azure 环境的更改列表。 要求人工手动评审 What-if 结果并批准工作流继续运行。
- 部署：将部署提交到资源管理器并等待部署完成。
- 版本验收测试：对已部署的一些重要资源运行基本的部署后检查。 这些检查称为“基础结构冒烟测试”。
你的组织的作业顺序可能有所不同，或者你可能需要将 Bicep 部署集成到部署其他组件的工作流中。 了解作业的工作原理后，可根据你自己的需求设计一个工作流。
每个作业都在从干净环境启动的新运行程序实例上执行。 因此，在每个作业中，第一步通常需要签出源代码。 还需要在与 Azure 交互的每一个作业中登录到 Azure 环境。
在本模块中，你将详细了解这些作业，并逐步生成包含每个作业的工作流。 你还将了解：
- 如果在之前的任何作业中发生任何意外情况，工作流如何停止部署过程。
- 如何将工作流配置为暂停，直到你手动验证了上一作业中发生的情况。