持续部署触发器和拉取请求触发器有什么区别？答案

【问题标题】：What is the difference between Continuous deployment trigger and Pull request trigger?持续部署触发器和拉取请求触发器有什么区别？
【发布时间】：2020-04-27 13:33:52
【问题描述】：

Azure DevOps Release 管道工件设置有 2 个选项：

连续部署触发器 - 启用触发器将在每次有新版本可用时创建一个新版本。
拉取请求触发器 - 启用此功能将在每次选定的工件可用作为拉取请求工作流程的一部分时创建一个版本

我试图了解这些选项在突出显示的部分方面有什么区别，以及构建验证策略是否会导致使用这两个选项触发发布，如果是，那么为什么我们有拉取请求触发器？

【问题讨论】：

标签： azure azure-devops azure-pipelines azure-pipelines-release-pipeline

【解决方案1】：

在我看来，这两个触发器有不同的工作范围。

根据我的测试，假设我们将一个 CI 构建设置为发布工件：

1.持续部署触发：

每当我们有新版本的构建时，它都会触发发布。这意味着无论构建管道是由手动运行、CI 触发还是分支策略中的构建验证触发的，都会在有一个较新的构建时触发发布。

2.拉取请求触发器：

它的范围较小，它将由构建管道触发，该管道由分支策略中的构建验证触发。

（这是由 PR 触发的，所以如果我们创建新的 PR=>它会触发 PR 构建=>它会触发 PR 发布）

如果我有任何误解，请随时纠正我。

更新1：

这是我的两个测试的一张照片：

Release-8 是由我手动运行的构建管道触发的，仅启用了 CD 触发。并且 Release-7 由 PR 构建触发，仅启用了 PR 触发。（我只在第 1 阶段启用 Pull Request 进行部署）

除了工作范围之外，这两个触发器在这里也有一点区别。目前阶段的 Pull Request Deployment 仅针对 Artifact 中的 PR 触发。

【讨论】：

好的，如果启用了“持续部署触发器”，那么“拉取请求触发器”选项是否多余？
pull request trigger 在工件与 pull request deployment 在阶段预部署条件下工作。所以有一个区别：如果我有一个具有两个阶段 A（PR 触发器启用）和 B（...未启用）的管道，工件的 CD 触发器将运行整个管道，而工件的 PR 触发器将只运行阶段 A。跨度>
所以虽然 PR 触发器的工作范围较小，但它并不是多余的，因为它可以控制是触发整个管道还是部分阶段！
@variable 如果有任何更新，请随时告诉我 :)
是的，这更有意义。谢谢。

【解决方案2】：

这很好地解释了这一点（取自documentation）：

拉取请求 (PR) 提供了一种审查代码的有效方法在合并到代码库之前。但是，某些问题可能是在构建代码并将其部署到环境之前很难找到。在引入拉取请求释放触发器之前，当一个 PR 提出，您可以触发构建，但不能触发部署。拉请求触发器使您能够创建拉取请求发布部署您的 PR 代码或 PR 构建以在之前检测部署问题代码更改被合并。您可以将拉取请求触发器与托管在 Azure Repos 或 GitHub 上的代码。

新构建基本上意味着您的管道已执行。

创建pull request trigger 您需要定义一个稍后将部署的工件。对于这种触发器，Azure Devops 运行您的管道并根据您的管道/构建定义生成工件，然后使用此工件进行部署。

两个触发器是相似的，不同的是你的代码是在合并到主分支之前还是之后部署的。

【讨论】：

你错了——我启用了“持续部署触发器”（未添加任何分支过滤器）并禁用了“拉取请求触发器”。现在，当我提出 PR 时，PR 会触发构建（因为我已经配置了构建验证）。构建完成后，它会触发发布。为什么当我禁用“拉取请求触发器”时会发生这种情况？仅当我在“持续部署触发器”中添加分支过滤器时，才会阻止在 PR 批准之前触发发布。

【解决方案3】：

PR 触发器是 CI 的一部分 - 当您将分支合并到 master 时适用

CD 触发器 - 仅适用于主分支

【讨论】：