6

假设我们继续在 TFS 2015 中为门控签入使用 XAML 构建定义,因为 vNext 系统不支持它们,是否仍然可以让多个门控签入并行运行?

我知道构建设置 UI 中有一个 Parallel 选项,但我不知道它是否也可以应用于 XAML 构建定义,以及还有哪些其他约束。

你可以在同一个盒子上并行构建(只要它支持多个代理)?

4

2 回答 2

9

相同定义的基于 XAML 的门控构建不能并行运行。我相信这是一个故意的限制。门控构建的目的是防止“损坏的”代码被提交到存储库。

当您对封闭式构建进行排队时,它会使用存储库中最新版本的代码,以及包含您刚刚提交的更改的搁置集。如果构建成功,则搁置集被提交并成为代码的最新版本。如果构建失败,则搁置集不会提交给 repo。

如果第二个门控构建被排队并同时运行,那么它无法知道第一个构建是成功还是失败,因此无法知道要在哪个版本上构建(它应该使用最新版本还是当前正在验证的搁置集)。如果第一次构建失败,那么第二次构建就可以了。但如果第一次构建成功,那么第二次构建不会针对正确版本的代码进行编译。更糟糕的是,第二个搁置集可能包含与第一个搁置集不兼容的更改,如果第二个构建成功,您可能会出现合并冲突或代码损坏。这违背了封闭式构建的目的。

门控签入即将构建 vNext,但我希望它们具有相同的限制。

门控构建与“CI”构建。

门控:如上所述,门控构建不能并行运行。当正确性比速度更重要时,应该使用它们。

CI:TFS 中的 CI 构建是更传统的触发构建。当开发人员签入更改时,这将提交到 repo 并触发构建。此时代码可能会被破坏(编译失败,导致单元测试失败等)CI 构建可以并行运行,但会增加损坏代码进入 repo 的风险,并且一个开发人员的错误可能会对团队的其他成员。

想法: 根据您的分支策略,您可以混合使用构建类型。例如,CI 构建在更改周转率很高的 dev 分支上,但如果构建每天中断几分钟,那么这并不是世界末日。只有开发团队受到影响,他们可以快速解决任何问题。对营业额较低的分支机构使用门控构建。例如,您的 Main 或 Release 分支只能在 sprint 结束时更新。

意见: 从原则上讲,封闭式构建听起来是个好主意,它们可以防止损坏的代码污染您的源代码控制存储库。这是一件好事。然而对我来说,快速反馈更重要。恕我直言,门控构建更像是一种垫片,以防止在提交之前不检查其代码编译或通过测试的“不体谅”开发人员。当然,我们都可能犯错误,但存在两种构建来告诉我们这一点,并让我们有机会修复错误。

本质上,我想我是在说这个。

CI:我可以信任代码吗?

Gated:我可以信任开发人员吗?

如果您有“永远不会损坏代码”的政策,那么您将不得不忍受封闭式构建的限制。如果您可以更灵活一点,并且您相信团队的其他成员不会做任何愚蠢/轻率的事情,那么您可以使用 CI 构建并获得并行构建的好处。

更新:2020 年 9 月 Buid vNext,现在称为 Azure DevOps Pipelines。门控签入的工作方式与基于 XAML 的构建相同,并且不能并行运行。这适用于 TFVC 用户。Git 用户可以通过在其分支策略(拉取请求)上使用构建验证来使用类似的功能

于 2016-01-14T12:32:57.673 回答
0

您可以在一台机器上拥有任意数量的构建代理。构建代理并行运行。两种构建系统都是如此。

于 2016-01-14T02:21:47.087 回答