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?

---

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.

---

There is not really a reason that I know of why not to do a Gated Check-in on every change you make. There is however (in general) a pre-requisite for doing Gated Check-in: your overall build time should not be longer that a few minutes, including any (unit) test you would like to have performed before the check-in is accepted. Otherwise it takes to much time for a check-in to get accepted, or worse for the developer, to get rejected. For a dev team it is also a bit more complex, or at least something to get used to.

Continuous Integration (in my opinion optimized in the form of Rolling builds) allows to have the developer check-in its code without having the uncertainty if it will be accepted or not. Important is that the dev will always have to be confronted as soon as possible with negative end results of a check-in. If you can achieve that, I like it better than Gated check-ins.

---

I prefer Gated Check-In's everywhere because it limits the pain to the developer checking-in rather than sharing that pain with the entire team when somebody (inevitably) makes a mistake.

As mentioned above, it's important to keep the Gated Check-Ins quick. I will sometimes have a Gated Checkin that runs the most important checks, then a CI build that kicks off after the Gated Checkin succeeds that runs more time-consuming checks.