Can we build multiple gated check-ins in parallel?

Question

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?

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)?

Answer 1

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.

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

Gated builds vs "CI" builds.

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

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.

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: Can I trust the code?

Gated: Can I trust the developers?

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.

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)