假设我们继续在TFS 2015中对门控签到使用XAML构建定义，因为vNext系统不支持它们，是否仍然可以并行运行多个门控签到？
我知道Build setup UI中有一个Parallel选项，但我不知道它是否也可以应用于XAML构建定义，以及还有哪些其他约束。
你可以在同一个盒子上并行构建（只要它支持多个代理）吗？
答案 0 :(得分：5)
基于XAML的相同定义的门控构建不能并行运行。我认为这是一个故意的限制。门控构建的目的是防止＆＃34;破坏＆＃34;代码从永远提交到存储库。
对门控构建进行排队时，它会使用存储库中最新版本的代码，以及包含您刚刚提交的更改的shelveset。如果构建成功，则搁置集将被提交并成为代码的最新版本。如果构建失败，则shelveset不会提交到repo。
如果第二个gated构建队列排队并同时运行，则它无法知道第一个构建是成功还是失败，因此无法构建要构建的版本（应该使用最新版本还是当前正在验证的shelveset ）。如果第一次构建失败，那么第二次构建就可以了。但如果第一个构建成功，那么第二个构建不会编译正确的代码版本。更糟糕的是，第二个shelveset可能包含与第一个shelveset不兼容的更改，如果第二个构建成功，则会出现合并冲突或代码损坏的可能性。这违背了封闭式构建的目的。
门禁签到即将建立vNext但我希望它们具有相同的限制。
门控版本与＆＃34; CI＆＃34;构建
门控：如所描述的那样，门控版本无法并行运行。当正确性比速度更重要时，应该使用它们。
CI ：TFS中的CI构建是一种更传统的触发构建。当开发人员签入更改时，会将其提交到repo并触发构建。此时代码可能被破坏（无法编译，导致单元测试失败等）CI构建可以并行运行，但会增加破坏代码进入repo的风险，并且一个开发人员错误会对团队的其他成员。
<强>思想： 根据您的分支策略，您可以使用构建类型的混合。例如，CI构建在dev分支上，这些分支具有较高的更改周转率，但如果构建每天损坏几分钟，则它不是世界末日。只有开发团队受到影响，他们可以快速解决任何问题。对于营业额较低的分支使用Gated构建。例如，您的Main或Release分支只能在sprint结束时更新。
<强>意见： Gated原则上听起来像一个好主意，它们可以防止破坏代码污染您的源代码控制回购。这是一件好事。但对我来说，快速反馈更为重要。恕我直言门控版本更像是一个垫片，以防止＆＃34;不注意＆＃34;在提交之前不检查其代码的开发人员编译或通过测试。当然，我们都可以犯错，但是存在两种类型的构建来告诉我们，并且给我们机会来修复错误。
从本质上讲，我想我是这样说的。
CI ：我可以信任这些代码吗？
Gated ：我可以信任开发者吗？
如果您的政策是＆＃34;没有破坏过的代码＆＃34;那么你将不得不忍受门控构建的局限性。如果您可以更灵活，并且您相信团队的其他成员不做任何愚蠢/不体谅的事情，那么您可以使用CI构建并获得并行构建的好处。
答案 1 :(得分：0)
您可以根据需要在一台计算机上拥有尽可能多的构建代理。构建代理并行运行。这两个构建系统都是如此。