TFS Check-In Policies Pack
There was a recent TFS Version Control Blog post which asked the community for feedback regarding TFS Version Control Check-In policies. The feedback questions were as follows:
- Would you like us to release a check-in policy pack together with some best practices and ship that out of band?
- If we do decide to do this then the next question becomes which policies are customers writing themselves that we can standardize and put in the pack?
- Which policies would customers like to see as examples?
The TFS Version Control Blog is ran by Mario Rodriguez who is a program manager on TFS Version Control. A couple of weeks ago he announced a small release-out of band- of new check in policies. The pack will contain four policies and they will also distribute the source code so you can use it as a reference.
Check-in policy granularity: there is one already in Code Gallery and what we will do is package this, change some of the UI and take out some of the complexity
Work-Item Associations: This is a very cool one that I hope many of you will find useful. You get to specify a query and if the associated work items by the developer are not part of the query results the check-in is blocked. This is very useful when it comes to making sure that check-ins are always associated with approved bugs.
Banned files: this policy allows you to specify a file extension or a regular expression in order to keep files that you don’t want out of version control. This is usually used for dll’s, build artifacts, or some website files that are automatically generated.
Check-in Comments: this policy gets shipped as part of the SDK. It looks at the check-in comments and makes sure it is not blank.
Some other cool Check-In policies already on the market are, not in any particular order:
Check for Comments: same as Check-in Comments.
Time That Task: gathers hours worked on a task during each check-in. This policy requires check-in to be associated with only one task that is in an "Active" status. It also gathers the number of hours worked on the associated task incrementing the completed hours and decrementing the remaining hours.
Code Review Workflow: doesn’t allow a check-in unless it has an associated Code Review work item (is included too), and that work item is set to approved. Only people in a TFS group named {Project}\Code Reviewers can set an item to approved.
Build Status: gets the last build status and validates a particular build type was actually passing before you check-in.
Custom Path: a mechanism that allows you to specify the source control path(s) that a particular policy is allowed to act on. This will allow for example a single Team Project to have one set of Code Analysis rules for a particular folder and completely different set of rules for another folder.
Summary
As you can see there are some great Check-In policies available. All of them are open source and I'll hope they soon will release this pack too on connect or codeplex.