26 March 2008

TFS Check-in Policies

Check-in policies are a mechanism for enforcing development practices across your development team. Check-in notes are a communication mechanism for collecting data from team members during the check-in process.

Out of the Box Check-in policies in VSTS 2005 :
  1. Code Analysis : Requires that code analysis is run before check-in.
  2. Testing Policy : Requires that check-in tests are completed before check-in.
  3. Work Items : Requires that one or more work items be associated with the check-in.
For More Help in Working with Check-In Policies and Notes
Recommeded Free Custom Check-in Policies :
  1. Code Comment Check-in Policy: This Team Foundation Server (TFS) Checkin policy ensures that the source code contains code comments (/// for C#, ''' for VB.NET) for classes, methods, properties, fields and events before checking it into Team Foundation version control (TFVC).
  2. Code Review Workflow Check-in Policy: This project is a combination of a Code Review Work Item and a Code Review Check-in Policy. The check-in policy doesn’t allow a check-in unless it has an associated Code Review work item, and that work item is set to approved. Only people in a TFS group named {Project}\Code Reviewers can set an item to approved: Code Review Work Item, Code Review Custom Check-In Policy and Code Reviewers Security Group.
  3. Banned files Check-In Policy: 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.
  4. Time That Task VSTS Check-In Policy: Custom VSTS check-in policy that 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. If the number of hours worked on code in check-in is greater than remaining work hours on the associated task, user will be asked to re-estimate the number or hours remaining for the task.
  5. TFS Custom Path Check-In Policy: The Custom Path Check-In Policy works in concert with existing Team Foundation Server (TFS) check-in policies, providing 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. It would also allow for filtering what specific items the rules work on for instance enforcing a Work Item for any check-in of files ending in ".cs, .sln, .csproj" but ignore the rule for all other check-ins.

Don't Forget to Send Notification E-mail on the Checkin Policy Override
kick it on DotNetKicks.com
Post a Comment