我们可以并行构建多个门禁登机手续吗? [英] Can we build multiple gated check-ins in parallel?

问题描述

假设由于vNext系统不支持XAML构建定义而在TFS 2015中对门禁签入使用XAML构建定义，那么仍然有可能使多个门禁签入并行运行吗?

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?

我知道在Build setup UI中有一个Parallel选项，但是我不知道它是否也可以应用于XAML Build定义，以及还有哪些其他约束.

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构建可以并行运行，但会增加破坏的代码将其纳入存储库的风险，并且一个开发人员的失误可能会对代码产生影响.团队的其他成员.

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分支只能在冲刺结束时进行更新.

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 :我可以信任代码吗?

CI: Can I trust the code?

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

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月 Buid vNext，现在称为Azure DevOps Pipelines.门控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屋！