对于TFS 2017 Gated Build中已提交的更改和其他功能，运行连续集成触发器的确切用途是什么？

Question

我对TFS 2017 Build触发器部分下提供的选项有些困惑。我有两个单独的构建定义，一个用于代码签入，即称为Gated Build，另一个是手动构建，在Gated构建完成后，我们将其用于CI服务器上的代码拖放\部署。

最近，我们想到了直接将Gated构建定义用于代码删除，这将节省分别触发手动构建的时间。但是，在执行此POC时，我对“触发器”部分中可用的不同功能的使用感到困惑，特别是为提交的更改运行连续集成触发器

我已将门控构建与发布定义直接链接，一旦门控构建完成，发布定义就会部署代码。我已经选择了构建中的两个选项，即对过滤器使用工作空间映射和对提交的更改运行连续集成触发器。这样，每当我签入代码时，一旦构建完成，就会触发Release定义并在服务器上部署代码，但是当我取消选择运行持续集成触发器以提交已提交的更改并签入代码时，它仍会部署只是因为它与Release定义链接而已。

我在Google上进行搜索，试图了解它的用法和其他功能，但了解不多，我也经历了link，只是知道它不会在变更集中显示NO CI 。

任何人都可以解释触发器中除预设的触发器外每个功能/选项的确切用法，或者如果有人知道触发器选项下所有功能的位置，请让我知道是否还有其他链接，博客，视频教程。用示例深入解释？

Answer 1

只是从字面意义上讲，它用于持续集成。

• 对于普通CI构建，只要有人签入代码，它就会构建，将更改签入TFS后，就会发生这种情况。
• [如果您选择门控登机，则只有在提交的更改成功合并并构建，这意味着仅构建成功，可以签入更改。

默认情况下，在完成门控检入过程并检入更改后，不会运行CI构建。但是，如果do希望在门控检入后运行CI构建，请选择< [运行连续的集成触发器以进行已提交的更改复选框。

有关所有触发器的更多详细信息，您可以参考下面的官方链接：

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops

总而言之，请取消选中该选项以防止触发持续集成构建。

---

关于为什么check-in an code it still deploys the code just because it is linked with the Release definition.，此触发器仅控制您的构建定义/管道，而不影响发布管道。

也有相应的Release Trigger。您应该在您的环境中仔细检查它。

有关在Azure DevOps中使用Gated Build的示例，您可以参考此博客-Gated Check-ins in Visual Studio Team Services using TFSVC and Git