This is the first in a series of planned blog posts on new features coming in Team Foundation Build 2010.
Team Foundation Build 2010 includes a new feature that lets you reject check-ins if the associated changes cannot be successfully (and automatically) merged with the current sources and built using a build definition with a new trigger. Changes that do merge and build successfully are committed to the version control repository on behalf of the user who originally submitted the check-in.
Configuring a Build Definition for Gated Check-in
Gated check-in is exposed as a new trigger type in the Build Definition editor. In the same way that you would enable continuous integration, you can enable gated check-in. When you do, be sure to review the workspace mapping associated with the build definition. Any check-in that affects that workspace mapping will be intercepted at the server and shelved (after prompting the user on the client-side for confirmation).
Gated Check-in Data Flow
Caveats, Provisos, etc.
There are some edge cases to be aware of when using gated check-in:
Here’s a somewhat dated, though still informative, video walkthrough of the gated check-in feature: