1

我对触发器部分下的 TFS 2017 Build 中提供的选项有点困惑。我有两个单独的构建定义，一个用于代码签入，即称为门控构建，另一个是手动构建，我们用于在门控构建完成后在我们的 CI 服务器上进行代码删除\部署。

最近，我们考虑直接使用 Gated 构建定义进行代码删除，这样可以节省单独触发手动构建的时间。但是，在执行此 POC 时，我对使用“触发器”部分中可用的不同功能感到困惑，尤其是“为提交的更改运行持续集成触发器”

我已经将 Gated Build 与 Release Definition 直接关联起来，一旦 Gated Build 完成，它就会部署代码。我在构建中选择了两个选项，即为 过滤器使用工作区映射和为提交的更改运行持续集成触发器。每当我签入代码时，构建完成后都会触发发布定义并将代码部署在服务器上，但是当我取消选择运行持续集成触发器以进行提交的更改并签入代码时，它仍然会部署代码，因为它与发布定义相关联。

我在谷歌上搜索并试图了解它的使用和其他功能，但不太了解，我通过链接也知道它不会在变更集中显示 NO CI。

任何人都可以解释触发器下存在的每个功能\选项的确切用途，除了计划的一个，或者如果有任何其他链接、博客、视频教程，请告诉我任何知道触发器选项下所有功能的解释的人深入举例？在此处输入图像描述

在 CI 构建中启用了持续集成选项，因为它会在门控构建完成后自动触发。 在此处输入图像描述

4

1 回答 1

1

正如字面意思一样，它用于持续集成。

  • 对于正常的 CI 构建，它会在有人签入代码时构建，它发生在更改签入到 TFS 之后。
  • 如果选择 Gated check-in，只有提交的变更合并构建成功才会接受签入，也就是说只有构建成功才能签入。

默认情况下，在门控签入过程完成并签入更改后，不会运行 CI 构建。但是，如果您确实希望在门控签入后运行 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 的示例，您可以参考此博客——在 Visual Studio Team Services 中使用 TFSVC 和 Git 进行 Gated Check-ins

于 2020-06-01T10:04:14.917 回答