我们可以并行构建多个门控签入吗? [英] Can we build multiple gated check-ins in parallel?

问题描述

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

Assuming we continue to use XAML build definitions for gated check-ins in TFS 2015 because the vNext system doesn't support them, is it still possible to get multiple gated check-ins running in parallel?

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

I know that there is a Parallel option in the Build setup UI but I don't know if it can be applied to XAML build definitions as well, and what other constraints there are.

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

Can you build in parallel on the same box (as long as it supports multiple agents)?

推荐答案

相同定义的基于 XAML 的门控构建不能并行运行.我认为这是故意限制.门控构建的目的是防止破坏"构建.代码永远不会被提交到存储库.

XAML based gated builds of the same definition cannot be run in parallel. I believe that this is a deliberate limitation. The purpose of a gated build is to prevent "broken" code from ever being committed to the repository.

当您将门控构建排入队列时，它会使用存储库中最新版本的代码，以及一个包含您刚刚提交的更改的搁置集.如果构建成功，则搁置集被提交并成为代码的最新版本.如果构建失败，则搁置集不会提交到存储库.

When you queue a gated build, it uses the latest version of the code in the repository, plus a shelveset containing the changes you have just committed. If the build succeeds then the shelveset is committed and becomes the latest version of the code. If the build fails then the shelveset is not committed to the repo.

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

If a second gated build was queued and ran at the same time then it cannot know if the first build will succeed or fail and therefore what version to build on (should it use the latest version or the shelveset that is currently being validated). If the first build fails then the second build would be OK. but if the first build succeeded then the second build is not compiling against the correct version of the code. Even worse, the second shelveset may contain changes that are incompatible with the first shelveset, leaving you with the possibility of merge conflicts or broken code if the second build succeeds. This defeats the purpose of a gated build.

门控签入很快就会构建 vNext，但我希望它们也有同样的限制.

Gated checkins are coming to build vNext soon but I would expect them to have the same limitation.

门控构建与CI"构建.

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

Gated: as described gated builds cannot run in parallel. They should be used when correctness is more important than speed.

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

CI: a CI build in TFS is a more traditional triggered build. When the developer checks in a change this is committed to the repo and a build is triggered. At this point the code could be broken (fails to compile, causes unit tests to fail etc) CI builds can run in parallel but increase the risk that broken code makes it in to the repo, and one developers mistake can have an impact on the rest of the team.

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

Thoughts: Depending on your branching strategy you could use a mixture of build types. For example, CI builds on dev branches which have a high turnover of changes, but if the build is broken for a few minutes a day then it's not the end of the world. Only the dev team are affected and they can fix any problems quickly. Use Gated builds for branches that have lower turnover. For example your Main or Release branch that may only be updated at the end of a sprint.

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

Opinion: Gated builds sound like a good idea in principle, they prevent broken code from polluting your source control repo. This is a good thing. However for me fast feedback is more important. IMHO Gated builds are more of a shim to prevent "inconsiderate" developers who don't check their code compiles or passes tests before the commit. Of course we can all make mistakes but both kinds of builds exist to tell us that, and to give us the opportunity to fix the error.

本质上我想我是在说这个.

In essence I guess I'm saying this.

CI:我可以信任代码吗?

Gated:我可以信任开发者吗?

Gated: Can I trust the developers?

如果您有永不破坏代码"的政策那么您将不得不忍受封闭式构建的局限性.如果您可以更灵活一点，并且相信团队的其他成员不会做任何愚蠢/不体贴的事情，那么您可以使用 CI 构建并获得并行构建的好处.

If you have a policy of "no broken code ever" then you'll have to live with the limitations of a gated build. If you can be a bit more flexible and you trust the rest of your team to not do anything stupid / inconsiderate then you can use CI builds and get the benefits of parallel builds.

更新:2020 年 9 月构建 vNext，现在称为 Azure DevOps Pipelines.Gated Checkins 的工作方式与基于 XAML 的构建相同，并且不能并行运行.这是针对 TFVC 用户的.Git 用户可以通过在他们的分支策略(拉取请求)上使用构建验证来使用类似的功能

Update: September 2020 Buid vNext, now called Azure DevOps Pipelines. Gated Checkins work the same way as XAML based builds and cannot be run in parallel. This is for TFVC users. Git Users are able to use similar functionality by using Build Validation on their Branch Policies (Pull Requests)

这篇关于我们可以并行构建多个门控签入吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！