Warren Seen

Interesting article about the use of the “Committer Model” in commercial software development, borrowed from the open source community.

The committer model solves a few problems of open source distributed development, but the primary one is that of trust: in a developers intent and in their competence. There are other issues that push different buttons depending on the project, but in the end, these are just indicators of intent or competence.

Personally, I think this is a bit of an extreme approach in the average commercial development project - certainly for teams under 10 developers I would call it excessive - as the same issues don’t apply in a commercial project.

Firstly, you must implicitly trust the intent of the developers which you are paying to write the software - and if you don’t, why are they working for you to begin with? Secondly, if you’ve hired them, then you already have made a decision based on their competence.

Fair enough, you don’t leave the keys to the castle with them on the first day, but not allowing them to check into a revision control system AT ALL is just asking for trouble in my opinion.

Still, the fact remains that to ensure quality, you can’t have code that was just checked in being rolled straight into a release and expect it to work. There needs to be some sort of gating to ensure that code has been relatively well exercised before it makes it into a release build. So how to compromise?

The way we approach this issue is to maintain a “trunk”, the latest code in development, and release branches, eg 1.0-release, 1.1-release, etc. We have a team of anywhere up to six developers working on various facets of the code at any time. The rules are simple:

1. don’t check into the trunk if your code won’t compile and pass our test suite.
2. if you have done significant work which has caused breakage, create a private branch until you can fulfill 1.
3. only one person is in charge of release “gating”, eg merging code from the trunk into a release branch.

This approach provides the ability for all developers to grab the bleeding edge code, whilst ensuring that code that gets merged into release branches is vetted accordingly. Fixes are applied within the trunk, and backported to release branches if necessary (eg for patch distribution)

In the case of simple changes, this probably takes all of 5 minutes to confirm that the fix does what it needs to do. Bigger changes usually require consultation or a walkthrough with the developer responsible.

In essence, this still implements the same safeguards as the committer model, however you also capture more change history as developers are able to commit small changes as they are made, reducing the risk of introducing widespread errors, or losing large amounts of work through equipment failure.

Personally, it’s rare for me to do a day’s work without committing it all - I’ve seen a hard drive die overnight enough times to be paranoid.

This entry was posted on Tuesday, March 28th, 2006 at 3:25 pm and is filed under c++, java, programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.