Team Foundation Version Control includes a feature called check-in polices which allows teams to execute a piece of code as part of the check-in process to ensure it meets certain constraints (policies). Out of the box there are three different policies that you can use – these are “Work Items”, “Code Analysis” and “Testing Policy”.
The “Work Items” policy is quite simple – it basically checks to see if you have a work item associated with the check-in and if you don’t it will generate a warning. You _can_ override the policy if you want to and continue to check code in. It will be interesting to see if development teams actually turn this on – for my money I would have made this a reasonable default since one of the key benefits of using TFS is being able to track changes to code against work that was assigned to the team.
With the “Code Analysis” and “Testing Policy” policies you get the opportunity to define more options, for example with the “Code Analysis” policy you can choose which FxCop rules you want to apply to your code on check-in and with the “Testing Policy” you get to choose which suite of tests you expect to pass before being allowed to check-in.
Once a policy is defined for your team project you can remove it or change its settings, although they aren’t applied retrospectively (trust me – this is a good thing).
Of course like most of the features in Visual Studio Team System extensibility points have been added so that you can create your own policies. This involves sub-classing the PolicyBase class which implements IPolicyEvaluation and IPolicyDefinition interfaces, these types are defined in the Microsoft.Team.Foundation.VersionControl.Client assembly (check out this post on how to get this assemblies added to the Add References dialog so you can reference them easily). James Manning does a fantastic job of show how to implement your own check-in policy and then register it so that it can be evaluated.
Now that you have gone and read all that background information I wanted to step back and think about what kind of policies people might want to use. James came up with a good generic one with the pattern policy which uses regular expressions to check whether file names are valid but I am sure there are people out there with additional requirements – what about these for starters?
- Profanity policy; looks for instances of profanity in code and comments.
- Code freeze policy; stops check-ins between certain dates and times.
- Code formatting policy; reads the source text and the code model to identify issues.
I am sure that some of the “Rules to Better” pages would be good sources of inspiration.