When to Use Gated Check-In?
I am using TFS 2010. Currently I use Gated Check-in build on the trunk (MAIN) branch only. And, I use CI on DEV and RELEASE branches.
- Why not use Gated Check-in build on all the branches?
- In what scenarios, you shouldn't use Gated Check-in build on DEV and RELEASE branches?
- Is it better to always use Gated Check-in build on every branch?
Answer
In our very large team, we also do gated in the main branch and CI in the dev/feature branches (many of them).
Gated offers more protection for the branch but with a very large team and large code base, it can back up the queue if the whole dev team is doing changes in that branch.
CI provides protection with a little more trust in the developers also knowing that any issues will get caught quickly. It's a bit more optimistic and allows the team to move much faster which is appropriate for a dev branch.
In both cases, devs run unit tests and test the code they are changing. CI (affects the team) and Gated (consumes time in the queue) should not replace testing - there should be a plausible explanation more complex than I didn't try it.
The whole team is in feature/dev branches using CI for the majority of the cycle and in higher branches with many more folks during end game stabilization - both of those latter conditions support the case for gated.
In a large team, we also need to get the CI builds and the rolling tests to be done in parallel to find issues quicker when build times are not trivial and full test suites are also not trivial. In that scenario, folks are checking in, the CI is picking up the last batch of checkin, running a build and when a build drops another machine is picking up and running the test suites.