Disadvantages of a gated check-in in TFS

Question

I've always worked with the Continuous Integration (CI) build in TFS. However, in my last project we started to use the gated check-in trigger.

Are there any disadvantages when using a gated check-in? Because if it prevents the team from checking in broken code, what's the purpose of a CI trigger?

Answer 1

Gated checkins make committing harder and slower. That is commonly a bad thing, because:

• In TDD, members should be able to push commits with failing tests
• Reporting bugs as failing tests is super useful
• When cooperating on a WIP (work in progress) branch, members should be able to push dirty changes to make them available quickly to others
• When working on a big change, it can be useful to let other members review unfinished work before investing the time to finish
• Many people like regularly committing incomplete work as a form of snapshot/backup
• committing incomplete work is great when frequently switching between branches (stashing only of limited help in particular for new files)
• QA should not be time-limited, but committing should not take long
• QA of code should happen in a clean environment anyway, the given local environment is most likely not as pristine as a CI server
• Similarly QA should often be done with a matrix of environments (different compiler version, different browsers, different OS, ...), the cost to set up are better invested in a central CI

So scenarios where gated checked are ok:

• Your VCS makes branching hard, or your company does not allow branching
• The project is tiny
• Only one developer
• No CI present

Answer 2

Gated checkin is a form of continuous integration build. In TFS, it creates a shelveset containing the code that's being validated, then runs a build of that code. Only if that code builds successfully and all configured unit tests pass does the code actually get committed.

Continuous integration is different -- in CI, the code is committed regardless of what happens as a result of the build. If a CI build fails due to bad code being committed, the code is still there, in source control, available for everyone to grab.

Now for the opinion-based part: Gated checkin is great if you have a large number of developers of varying levels of skill/experience, since it prevents broken code from going into source control. The downside is that it increases the time between code being committed and code being available for others, and thus can lead to situations where people are sitting around twiddling their thumbs waiting for the build to complete successfully.

I recommend using gated check-in as a stopgap. If you have a ton of gated check-in build failing, then it's doing its job and preventing bad code from getting committed. If, over time, the team matures and gated check-in builds fail infrequently, then it's serving less purpose and should be switched over to continuous integration and correcting failing builds as they come, instead of delaying every commit in the off chance there's a problem.