假设我们在TFS 2015中继续使用XAML生成定义进行门控签入，因为vNext系统不支持这些定义，那么仍然可以并行运行多个门控签入吗？
我知道Build设置UI中有一个Parallel选项，但我不知道它是否也可以应用于XAML构建定义，以及还有什么其他约束。
你能在同一个盒子上并行构建吗（只要它支持多个代理）？
相同定义的基于XAML的门控生成不能并行运行。我认为这是一种蓄意的限制。门控建筑的目的是防止"；破碎的"；代码从未提交到存储库。
当您对封闭构建进行排队时，它将使用存储库中最新版本的代码，以及包含您刚刚提交的更改的搁置集。如果生成成功，则搁置集将被提交并成为代码的最新版本。如果生成失败，则搁置集不会提交到repo。
如果第二个门控生成被排队并同时运行，则它无法知道第一个生成是成功还是失败，因此无法知道要在哪个版本上生成（它应该使用最新版本还是当前正在验证的搁置集）。如果第一次生成失败，那么第二次生成就可以了。但如果第一次成功，则第二次编译没有使用正确版本的代码。更糟糕的是，第二个搁置集可能包含与第一个搁置集不兼容的更改，如果第二次生成成功，则可能会发生合并冲突或代码损坏。这违背了封闭式建筑的目的。
门控签入很快就会构建vNext，但我希望它们也有同样的限制。
网关构建与"；CI"；构建
门控：如上所述，门控构建无法并行运行。当正确性比速度更重要时，应该使用它们。
CI：TFS中的CI构建是一种更传统的触发构建。当开发人员签入更改时，该更改将提交给repo并触发构建。此时，代码可能会被破坏（编译失败、导致单元测试失败等）CI构建可以并行运行，但会增加被破坏的代码进入回购的风险，开发人员的一个错误可能会对团队的其他成员产生影响。
思想：根据您的分支策略，您可以混合使用构建类型。例如，CI构建在具有高变化率的开发分支上，但如果构建每天中断几分钟，那么这就不是世界末日。只有开发团队受到影响，他们可以快速解决任何问题。对营业额较低的分支使用Gated构建。例如，您的Main或Release分支可能只在sprint结束时更新。
意见：原则上，门控构建听起来是个好主意，它们可以防止损坏的代码污染您的源代码管理回购。这是一件好事。然而，对我来说，快速反馈更重要。IMHO门控构建更像是一个垫片；不体贴的"；不检查代码的开发人员在提交前编译或通过测试。当然，我们都可能犯错误，但这两种构建的存在都是为了告诉我们这一点，并给我们纠正错误的机会。
从本质上讲，我想我是这么说的。
CI：我可以信任代码吗？
Gated：我可以信任开发人员吗？
如果你有一个"；从来没有坏代码"；那么您将不得不接受封闭构建的限制。如果你可以更灵活一点，并且你相信团队的其他成员不会做任何愚蠢/不体贴的事情，那么你就可以使用CI构建并获得并行构建的好处。
更新：2020年9月Buid vNext，现在称为Azure DevOps管道。门控签入的工作方式与基于XAML的生成相同，不能并行运行。这是为TFVC用户准备的。Git用户可以通过对其分支策略（拉取请求）使用构建验证来使用类似的功能
您可以在一台机器上拥有任意数量的构建代理。生成代理并行操作。这两种构建系统都是如此。