Question

Using visual studio 2012 and tfs 2012.

What’s the difference between “build” checkin policy and a gated checkin? They both seem to require a successful build in order to checkin.

What’s the advantages and disadvantages of them both?

Should one be used in preference to the other or can/should they both be used together?

Answer 1

Note: the below answer should actually be referring to a different policy (see comments), the builds policy stops you checking in if a build is broken, which should never happen if you’re also using gated checkins. This means there’s little benefit to having both.

The build checkin policy requires you to build the code on your machine before you can check in.

A gated checkin shelves your changes and runs a tfs build server build (and anything else like unit tests etc), then if the build passes the shelve set is merged into source control. If the build fails you get a popup and need to fix the issue before any code can be commited.

With the checkin policy it’s still possible to miss files from the checkin meaning it won’t build for other developers. The gated checkin guarantees what is in source control builds.

Because the checkin policy uses your box for the build it doesn’t put as much strain on the build server, this can be a benefit if you don’t have the resources to run enough build servers to have short queues. Having a checkin policy before a gated checkin should help reduce the number of failed builds wasting your servers time. So there are benefits from having both enabled.

If your build server is overloaded then a gated checkin can delay other developers getting access to the code while they wait for the build to happen.