What Check-In Policies should be considered for version control?

Question

I'm tasked with helping to set up the process templates and check-in policies for my company's TFS 2008 installation.

Aside from three check-in policies (a check-in action must have comments against it, a code file must be peer-reviewed, there must be a work item associated with a check-in), I have been asked to consider and implement any others.

What are some of the most important or useful policies to enforce for version control?

Answer 1

Some rules that we follow in our company:

• Commit all changes related to the same task at once (that will help review the changes and future rollbacks or merges if needed).
• template based comments (eg: prefix all comments with a code that represents what was done, + for adds, - for removes, * for updates, ! for important modifications, etc).
• Obviously always check-in code that compiles, and finished work to the main-line.
• check-in daily unfinished work to branches.

Answer 2

Don't break the build! Of course, finding an automated way to check on that and reject the check-in are the challenge.

Answer 3

Frankly, the less policies, the better. The more policies you have, the greater the incentive for NOT using version control. What happens then is:

• Code is developed on parallel, uncontrolled source control systems, and just the final revision goes to the official one.
• People delay committing as much as possible, decreasing visibility of what they are doing to other developers.
• People will actually avoid committing something if they can get away with it, and some will find a way to get away with it.

In fact, I think your three check-in policies are already too much. For instance:

• Having code being peer-reviewed before check-in makes it much more difficult to have work-in-progress stored there. Instead, if the source control system allows it (and many do), control whether the source is peer reviewed or not. With some systems you can create a life cycle for a revision, with others you might create branches, and still others you might use tags.
• Having a work-item associated with a check-in makes it impossible for developers to do exploratory programming, or having initiative on possible improvements. It stifles the developers. Instead, make sure that any revision going into integration tests or user acceptance tests, not to mention production itself, is associated with a work item.

This might sound anti-Enterprise, but it's just some things we have learned in a few decades of software development. Most enterprise organizations haven't been clued in to this, but, eventually, they will. So, you might go the very opposite way, but don't say no one ever told you.

I recommend the Agile Manifest, and, particularly, Lean Software Development for general principles.

Or, taking Stack Overflow design philosophy into account, make the system reward the behavior you want.

Answer 4

Try to keep the number of developers working on the same branch small. That way the branch stays stable with respect to compilation, the unit tests, and regressions. It's a nightmare if a developer does a check in which compiles but his code breaks a key area of the application (such as login).

If you really have to have more than 10 developers checking code into the same branch, we've started an email policy where the developer checking in warns everyone that they're checking in, so that no one attempts to update their copy of the branch in the midst of a check in. Sometimes, we've had to have the converse, where we set aside an time in the date to prohibit check ins, so that updates are safe.

Answer 5

The ones we use where I work on TFS are:

• Code Analysis
  • This ensures that all the code was compiled on the devs machine before it was checked in
• Work Item Association
  • If you've done a change there should have been an assigned task!
• Last Build Successful
  • Using the TFS Build Server to check that the current code in source control compiled on an independant machine
• Check In Comments (part of the TFS Powertools - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx)
  • It's good to be able to see a summary of the check in without having to go to the work item(s)

Answer 6

The fewer the better.

Usually in an organization you want to ease the friction of check-in to ensure that you are encouraging developers to make frequent small discrete check-ins rather than checking out a load of stuff at once. Then again you want to ensure that you have a working codebase for everyone who needs it and are capturing the data that you need to improve your software delivery process.

Personally, a policy to enforce changeset comments and a work item association policy are ok - as they capture meta-data that is very easy to remember at the time but hard to find afterwards. It also encourages developers to get into the habit of having a work item to track all pieces of work - even experimental development or spikes.

The peer review process might be better performed using branching or another process rather than forcing a peer review on every check-in - however that depends on your process. Remember as well that you can have mandatory check-in notes in TFS to capture meta-data such as code reviewer. A check-in note is slightly different to a check-in policy and is often confused.

If you want read more discussion about check-in policies, take a look at a blog post I did on the balancing act a while ago. Also to hear some more discussion about check-in policies, I recorded a podcast recently with a fellow Team System MVP talking about their use of TFS and it might be interesting (Radio TFS, Using TFS with Ed Blankenship). Finally we also did a Radio TFS episode all about check-in policies in 2008 that might be of interest.