As I’m the responsible guy for the TFS 2008 server on our project, I started to add some custom policies to the check-in.  Later I also add the build server part.

You can use several check-in policies.  After talking with a few other colleagues and friends about which policies should be added, we came to following list, which is a kind of standard for most of the projects where they use TFS.

1. Associate with your work item
2. Last build must be successful.
3. Mandatory add check-in comments
4. Check if all methods have comment
5. Code analysis

Some check-in policies are not by default installed.  So for those, we have to install them for each developer.  These are the tools/policies we need to install extra:

1. Mandatory add check-in comments : Comes with the power tools.  Install only the Check-in policy pack on the developers machines.  Download it at http://msdn2.microsoft.com/en-us/tfs2008/bb980963.aspx.
2. Code Comment Check-in policy (CCCP): download it at http://www.codeplex.com/TFSCCPolicy.  Be aware that the current version (v 2.1.1) doesn’t work with TFS 2008.  If you want to add this, they have currently following beta version 3.0.0.1 Beta 1.

Associate Work items with check-in

Why would add Work items with your check-in?
If a build breaks, it is important that you know what change sets are associated with this build and what work items those change sets are associated with. With this knowledge, you can identify the developer responsible for checking in the changed code and the area of the project on which he or she is working. 

For a build to be associated with a set of completed work items, each check-in must be associated with a work item. These check-ins are represented as change sets associated with the build, and it is possible to trace from build to change set to work item.

How do add this policy?

1. In Team Explorer, right-click your team project, select "Team Project Settings", and then click "Source Control".
2. Click the "Check-in Policy" tab.
3. Click Add and then select and configure the "Work Item" check-in policy.

What gives this for the developers?

After they have changed their code and they want to perform check-in.  The check-in policy dialog appears.

When they press Check In, they got the message that not all policy requirements have been satisfied. 

They can check the policy warnings to see which policies they need to approve.

So to solve this, they have to go to the work items tab and choose their related work item.  By default the check-in action will state that the Work item is resolved.  But in case you still want to have the work item active, you need to change the Check-in action to Associate.

Last build must be successful

This policy requires that the last build was successful before the developer can check his code.  This is not the same as the standard Build policy.  The standard build policy is affecting the CI build.  If this build fails, developers can’t check in, till the problem is solved.
To add that the last build of the developer must be successful, we have to use a little trick.  We will use the Code Analysis policy, but without any rules selected.

This policy is makes sure that the developer at least check-ins a buildable change set.  Normally in this case our build server will not break on the build.

How do add this policy?

1. In Team Explorer, right-click your team project, select "Team Project Settings", and then click "Source Control".
2. Click the "Check-in Policy" tab.
3. Click Add and then select and configure the "Code Analysis" check-in policy.
4. In the settings, uncheck all rules and the option “Enforce Code Analysis For Managed Code”
   

What gives this for the developers?

When a developer wants to check-in his code which doesn’t build or isn’t a build after changing code on his machine, he will get a check-in policy error for the code analysis.

I will explain the other Check-in policies in my next blog post, so stay tuned.