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 an

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
• Only specific long-lived branches are protected by the gates (but that's not an alternative to CI)