连续部署触发器和请求请求触发器之间有什么区别？

Question

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

1. 连续部署触发器-启用触发器将在每次[[有新版本可用时创建一个新版本。
拉动请求触发器-启用此功能将在拉动请求工作流程中每次
2. 选定的工件可用
时创建一个发行版

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

Answer 1

我认为，这两个触发器的工作范围不同。

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

1。

连续部署触发器：

[只要我们拥有Build的新版本，它就会触发发行。这意味着无论构建管道是由手动运行，CI触发还是分支策略中的构建验证触发的，都将在存在一个新的构建时触发发布。

2。

拉出请求触发器：

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

（（由PR触发，因此如果我们创建新的PR =>它将触发PR build =>它将触发PR释放）

如果我误解了，请随时纠正我。

Update1：​​

这里是有关我的两次测试的图片：

Release-8是由我手动运行的构建管道触发的，仅启用了CD触发。 Release 7由PR构建触发，仅启用PR触发。 （我仅在阶段1中启用拉取部署请求）

除了工作范围外，这两个触发器在这里也有一点区别。目前，阶段中的“拉取请求部署”仅适用于工件中的PR触发器。

Answer 2

这很好解释（摘自documentation：

拉动请求（PR）提供了一种有效的方式来审查代码在将其合并到代码库之前。但是，某些问题可能是在构建代码并将其部署到环境之前很难找到。在引入拉取请求释放触发器之前，当PR提出来，您可以触发构建，但不能触发部署。拉请求触发器使您能够创建拉取请求版本部署您的PR代码或PR构建以在发现部署问题之前代码更改被合并。您可以将拉取请求触发器与代码存储在Azure Repos或GitHub上。

New build基本上意味着您的管道已执行。

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

两个触发器都是相似的，不同之处在于何时将您的代码在合并到主分支之前或之后进行部署。