Which Check-in policies do you use with your projects?
Team Foundation Server allows an administrator to define a Check-in policy to ensure all code that is checked in conforms to a certain standard and that a minimal set of quality attributes have been applied to that code. Not all of these policies make sense in every situation and implementing them can be negatively perceived by the development team. It's often better to explain (over and over again, in person) the benefit of doing things right, them let a tool tel people what to do.
Please comment on any great policies I might have missed or ways to be able to remove these policies in place completely!
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.
-
- This policy allows you to specify a couple of branches that can only receive merges of already checked in work on another branch.
-
- I've sometimes used these to ensure no
/bin/debug,.exeor.dllwas checked into a//src/folder in TFS.
- I've sometimes used these to ensure no
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 polciies 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.
Based on my answer to a (rather old) question on StackOverflow.