User experience with Gated Check-in

When your TFS administrator has enabled the Gated Check-in feature you do not notice anything at first. However, when you check in files a new dialog box appears:

As you can see in the green-marked area the system has created a Shelveset where your changes are stored temporary. The changes are then being built using the build server. If the build is successful the changes are committed, otherwise they are not – which means your changes have not been checked-in.

The red-marked area shows a check-box that makes it possible to choose if your changes should be kept locally or not. Default is that they are preserved (as in the picture). More about this later.

In the Build Explorer a build that is triggered via a Gated Check-in is indicated by an icon showing up next to the build, see this image:

Above the green indicator (that I put there) you can see the icon. In the same place you see the clock icon if it is a scheduled build and so on.

When the build has been finished it either when all green and the check-in has committed, or an unsuccessful build was the result, and then the check-in was Rejected. As a user you notice this as a pop-up dialog is diaplayed. Below you can see the two different dialogs:

In the case where the Check-in has committed you probably want to make sure your workspace looks the same as what has been checked-in. You do this by pressing the Reconcile button. If you checked the “Preserve my pending changes locally” you the tool will sync everything for you. You can find the same functionality in the Build Explorer if you bring up the build log. There you can see if the check-in was Committed or Rejected and you can perform the Reconcilation from there as well.

Some important point to think about:
– Your changes are not Check-in if the build was not successful. A partially successful build is considered unsuccessful.
– If the build works locally, but not at check-in, one thing to look for is project reference problems

This feature will most certainly change the work behavior of the users. Make sure not to get any strange mis-behavior…

Good luck!

Advertisement

Configuring Gated Check-In

You have probably heard of a new feature in Visual Studio/TFS 2010 called Gated Check-In. The problem this is supposed to solve is the problem of broken builds – when a check-in makes the next build fail. In order to start using this feature you configure it in a certain way.

First you create a Build definition pointing out the solution you want to build in your “Gate”. You configure it to trigger at Gated Check-in as below.

Next important step is to chose when this build should trigger. This is configured under the Workspace tab in the Build definition. By pointing out a workspace location, whenever trying to check-in a file to that workspace a new build is triggered. In our current application we have three different solutions and each has its own build associated to it.

The functionality you get will make it impossible to check-in anything whenever this build is unsuccessful. Remember that a partially successful build, for example when some unit tests fail, will be considered an unsuccessful build.

I have also posted about the user experience Gated Check-in, se this post https://tomasscott.wordpress.com/2010/02/07/user-experience-with-gated-check-in/