tfs - 我们可以并行构建多个门控签到吗？

Question

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

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

你能在同一个盒子上并行构建吗(只要它支持多个代理)？

Answer 1

相同定义的基于 XAML 的门控构建不能并行运行。我认为这是故意限制。门控构建的目的是防止“损坏的”代码被提交到存储库。
当您将门控构建排入队列时，它会使用存储库中最新版本的代码，以及一个包含您刚刚提交的更改的搁置集。如果构建成功，则搁置集被提交并成为代码的最新版本。如果构建失败，则搁置集不会提交到存储库。
如果第二个门控构建排队并同时运行，那么它无法知道第一个构建是成功还是失败，因此无法知道要构建的版本(它应该使用最新版本还是当前正在验证的搁置集)。如果第一个构建失败，那么第二个构建就可以了。但是如果第一个构建成功，那么第二个构建就不会针对正确的代码版本进行编译。更糟糕的是，第二个搁置集可能包含与第一个搁置集不兼容的更改，如果第二个构建成功，则可能会出现合并冲突或损坏的代码。这违背了门控构建的目的。
门控 checkin 很快就会构建 vNext，但我希望它们有相同的限制。
门控构建与“CI”构建。
门控 :如前所述，门控构建不能并行运行。当正确性比速度更重要时，应该使用它们。
CI :TFS 中的 CI 构建是更传统的触发构建。当开发人员 checkin 更改时，这将提交到存储库并触发构建。此时代码可能会被破坏(编译失败，导致单元测试失败等) CI 构建可以并行运行，但会增加被破坏的代码进入 repo 的风险，一个开发人员的错误可能会对团队的其他成员。
感想:
根据您的分支策略，您可以混合使用构建类型。例如，CI 构建在具有高更改周转率的开发分支上，但如果构建每天中断几分钟，那么这并不是世界末日。只有开发团队受到影响，他们可以快速解决任何问题。对营业额较低的分支机构使用 Gated 构建。例如，您的 Main 或 Release 分支可能仅在冲刺结束时更新。
意见:
原则上，门控构建听起来是个好主意，它们可以防止损坏的代码污染您的源代码控制存储库。这是一件好事。但是对我来说，快速反馈更为重要。恕我直言，门控构建更像是一种垫片，以防止“不体贴”的开发人员在提交之前不检查其代码编译或通过测试。当然，我们都可能犯错误，但两种构建都可以告诉我们这一点，并让我们有机会修复错误。
从本质上讲，我想我是在说这个。
CI : 我可以信任代码吗？
门控 : 我可以信任开发商吗？
如果您有“永远不会破坏代码”的政策，那么您将不得不忍受封闭构建的限制。如果您可以更灵活一点，并且您相信团队的其他成员不会做任何愚蠢/不体贴的事情，那么您可以使用 CI 构建并获得并行构建的好处。
更新:2020 年 9 月
构建 vNext，现在称为 Azure DevOps Pipelines。 Gated Checkins 的工作方式与基于 XAML 的构建相同，并且不能并行运行。这适用于 TFVC 用户。 Git 用户可以通过在他们的分支策略(拉请求)上使用构建验证来使用类似的功能