上一篇

下一步

使用触发器控制管道的运行时间

已完成

现在你已经创建了一个可将 Bicep 文件部署到 Azure 环境的工作管道。 但是，无论何时更改文件，都必须手动运行管道。 在本单元中，你将了解如何在 Bicep 代码更改时触发管道自动运行。

注意

本单元中显示的命令用于说明概念。 请暂时不要运行这些命令。 稍后你将练习在此处学到的知识。

什么是管道触发器？

管道触发器是一种条件，满足此条件时，会基于你创建的规则自动运行管道。 你可以将触发器设置为按计划的时间间隔运行管道。 还可以将触发器设置为每次在存储库中的文件发生更改时运行管道。 你可以选择第二个选项，因为每次更改代码时都运行所有测试和部署步骤是很好的做法。

如果不使用自动触发器，可能会有人对 Bicep 文件进行更改，甚至提交并将其推送到存储库。 但如果他们忘记运行管道，则 Bicep 文件中的资源定义与部署到 Azure 环境的资源之间将存在差异。 假设已完成了几个提交和推送，但尚未部署。 如果有人在其中一项更改中引入了 Bicep 文件中的错误或错误配置，可能很难在稍后部署的多个提交中跟踪这些错误。 经过一段时间后，你将不再相信你的 Bicep 代码真实反映了你的基础结构，其价值会降低。

将管道设置为每次更新文件时都运行时，推送更改的那一刻，管道就开始运行。 你可获得有关更改有效性的即时反馈，并可确保你的生产环境始终最新。

分支触发器

常见的触发器类型为分支触发器，也称为连续集成触发器或 CI 触发器。 使用分支触发器时，每次对特定分支进行更改时，管道都会运行。 如果提交更改并将其推送到其他分支，则不会触发管道，管道不会运行。 对于默认或主分支，通常使用此类型的触发器，并使用以下代码：

trigger:
- main

当多个分支更改时触发

可以设置触发器，以在特定的分支或分支集上运行管道。 例如，假设创建了发布分支，其中包含将为项目的特定版本部署的代码。 可以使用 release/v1、release/v2 等分支名称。 你希望每当代码在以名称 release/ 开头的分支上发生更改时都运行管道。 可以将 include 属性与 * 通配符一起使用：

trigger:
  branches:
    include:
    - main
    - release/*

还可以排除特定分支。 假设你正在与项目的团队成员合作。 你的同事创建了功能分支以在 Bicep 文件中验证他们的想法。 所有功能分支均采用 feature/add-database、feature/improve-performance 这类命名方式。 你希望在同事创建的功能分支以外的其他所有分支上自动运行管道。 通过使用 exclude 属性，可以确保管道不会因功能分支的更改而自动触发：

trigger:
  branches:
    include:
    - '*'
    exclude:
    - feature/*

提示

请注意 include 筛选器中通配符周围的引号。 YAML 文件格式要求在将单个 * 字符用作通配符时用引号引起来。

路径筛选器

有时，存储库中会有与部署无关的文件。 例如，在存储库中，你可能有一个包含 Bicep 代码的 deploy 文件夹和一个包含文档文件的单独的 docs 文件夹。 你希望每当有人更改 deploy 文件夹中的任何 Bicep 文件时，系统都会触发管道，但不希望在有人仅更改文档文件时触发管道。 若要设置触发器来响应存储库中特定文件夹的更改，可以使用路径筛选器：

trigger:
  branches:
    include:
    - main
  paths:
    exclude:
    - docs
    include:
    - deploy

如果有人提交仅更新某个文档文件的更改，管道不会运行。 但是，如果有人更改了 Bicep 文件，或者除了更改文档文件之外还更改了 Bicep 文件，触发器会运行管道。

安排管道自动运行

可以按计划运行管道，而不是为了响应文件更改而运行管道。 例如，你可能每晚运行一次 Bicep 代码发布，或者每天早上自动部署一个测试环境。 使用 schedules 关键字代替 trigger，并使用 cron 表达式设置频率：

schedules:
- cron: "0 0 * * *"
  displayName: Daily environment restore
  branches:
    include:
    - main

备注

cron 表达式是一种特殊格式的字符序列，用于设置事件发生的频率。 在本例中，0 0 * * * 表示每天在 UTC 午夜时间运行。

还可以设置要用于计划事件的存储库分支。 管道启动时，它使用在计划中设置的分支中的最新版本的代码。

使用多个触发器

可以结合使用触发器和计划，如以下示例中所示：

trigger:
- main

schedules:
- cron: "0 0 * * *"
  displayName: Deploy test environment
  branches:
    include:
    - main

如果在同一管道中创建分支触发器和计划触发器，则每次在触发器中设置的分支和设置的计划中的文件发生更改时，都将运行该管道。 在本例中，管道会在每天 UTC 午夜时间运行，还会在将更改推送到主分支时运行。

提示

为每个管道设置触发器是一种很好的做法。 如果不设置触发器，则默认情况下，只要任何分支上的任何文件发生更改，管道就会自动运行，而这并不是你所希望的。

并发控制

默认情况下，Azure Pipelines 允许管道的多个实例同时运行。 如果在短时间内对分支进行多次提交，可能会发生这种情况。

在某些情况下，有多个并发运行的管道不是问题。 但在使用部署管道时，可能会很难确保管道的运行不会以意想不到的方式覆盖 Azure 资源或配置。

若要避免这些问题，可以将 batch 关键字与触发器一起使用，如以下示例中所示：

trigger:
  batch: true
  branches:
    include:
    - main

触发触发器时，Azure Pipelines 确保它等待所有活动的管道运行完成。 然后，它将开始一个新的运行，其中包括自上次运行以来累积的所有更改。

继续