TFS Check-in Policy Best Practices / Your experience

We are going to use TFS 2010 for a new project and I'm looking for a best practice and knowledge/experience about using the policy check in option when developing as a team. I've found information about all this but not really that much information about best practices and what dev teams opinions and experiences about policies, which they used and perhaps should have开发者_开发技巧 used.

• Which policies did you use?
• What was your experience?
• What would you recommend?

For instance have you used Microsoft Minimum Recommended Rules and did you use them all?

Information and your experience is appreciated.

The most essential check-in policies are:

• Comment Policy - require comments for all check ins.
• Work Item association - this should be mandatory as without it you cannot group change sets to a particular stream of work. You need to be able to do this for merging and rolling back changes wholesale.
• Gated Check In - While not a policy as such (you need to create a gated build) it prevents developers from checking in code that breaks the build. If you created linked builds across your code base you can ensure your solutions are never broken by check in again. I've done it and it works.

There are many others (we use a Gemini item association policy) and you can write your own as we have. It's not that hard and you can tailor them to fit.

This is more of a discussion question, which is not the type of question StackOverflow usually wants, but I'll bite.

The policies that for me make sense are:

• Builds policy
  • This policy prevents a build queue of failed builds after someone breaks the build. You will actually be warned that the build is currently broken, so that someone can fix the build before continuing.
• Work Item Association
  • We need work item association to ensure we can trace checkins to work being done an through that to testcases.
• Work item Query
  • We want people to select their work from the current sprint/iteration. So it's handy to verify that the work people are checking in against is actually pre-approved work.
• Custom Path Policy
  • We use this policy once in a while in Team projects that house more than one project and where we want to increase quality or security on one project, but are not interested in bothering the other project. Or to prevent certain checkins on the current release branch, but don't want such stringent policies on an old release that is still being maintained.

We verify a few things which you could do through checkin-policies by failing the CI build instead. This is done mostly to save time on the developers machines.

• Code Analysis Policy.
  • Instead of using a checkin policy for this, we use a CI build which will fail if certain Code Analysis rules are broken. This allows us to let the developer builds skip Code Analysis on every build. People will learn pretty quickly how to prevent these rules from triggering anyways.

We're not using any other policy. The Require comment for change set policy is something we sometimes use, but most teams actually don't need a policy for this after some time. Having no comments on a checkin is frowned upon by most and this resolves itself.

We had a couple of projects where time tracking was done (for MSF CMMI) and we used a custom policy to ensure people updated their hours on every checkin.

We're not using any policy to enforce Code Coverage or Number of warnings. These can be added to the build if needed through build process customization.

We use Gated Checkins on branches that require additional verification. Such as release branches and branches that are followed by automatic deployment.

We often allow developers to by-pass any checkin policy without penalty. Same goes for gated Checkins. It is up to the developer to use these rights wisely. Breaking a deployment is something you cannot do too often before being noticed by the team ;).

There are a few interesting custom policies out there as well, but I know only a handful of people who actually went as far as to use these.

• Merge only policy
  • This policy allows you to specify a couple of branches that can only receive merges of already checked in work on another branch.
• Forbidden Patterns Policy
  • I've sometimes used these to ensure no /bin/debug, .exe or .dll was checked into a //src/ folder in TFS.

There are a few more policies from 3rd parties, but I've never used those. These include:

• The Checkin Policy Pack and that page lists a couple of extra policies that I've never had to use either.

One of the reasons for not using too many 3rd party policies is that all team members need to have the polcies installed on their machines. The Team Foundation Server Power Tools can help you out with the distribution, but those are not deployed and configured on all developers workstations by default.

Also available in blog form.

Try each of the check-in policies to see if they provide value to your team.

Some of our Team Projects require only a check in comment. Some require a comment and a work item. Some require a successful build. It all depends on what the team requires.

Don't try to follow someone else's best practice. Determine what works in your environment.