Share via

Coming soon – Gated Check-in

  • Article

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 

image

Caveats, Provisos, etc.

There are some edge cases to be aware of when using gated check-in:

  • If you have two build definitions with overlapping workspace mappings that are both gated and a user submits a check-in that affects them both, the user will get to pick which one gets built to verify their changes.
  • If the changes merge and build successfully, they get committed to the repository. This leaves the user’s local workspace in a state where they have pending changes that have actually already been committed. There is an “Update Workspace” command that fixes up their workspace to clear the pending state from those changes but it can create some confusion. It’s also important to note that, due to the automatic merge, the changes that get committed may not be identical to the changes the user submitted.
  • Builds triggered by gated check-ins are serialized so that only one build of a gated build definition can execute at a time (even within a pool of build resources). This was done to preclude the possibility of conflicting changes getting submitted.

Here’s a somewhat dated, though still informative, video walkthrough of the gated check-in feature: