Disadvantages of a gated check-in in TFS

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.

Gated check-ins are fundamentally flawed because they validate dirty local state, not versioned state, so they cannot replace independent checks based on a clean slate (such as in a CI pipeline). Similarly QA often needs to 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.

Gated checkins also 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 cannot be time-limited, but committing should not take long

So scenarios where gated checked are ok as workaround or quick and dirty mitigation:

• Your VCS makes branching hard, or your company does not allow branching
• The project is tiny
• Only one developer
• No CI present
• Only specific long-lived branches are protected by the gates (but that's not an alternative to CI)