MostlyGeek

With the sutton.com launch just around the corner we found ourselves needing to switch from a liberal development mode to responsible release management mode. Maintaining a medium sized software application like sutton.com requires a lot of behind the scenes management that only the developers usually see. I hope this post shares some experience on what we do here at SGRS to keep our code manageable.

First we use Subversion as our source control system. It is open source, free and is an accounting system for our code. It allows us to keep a history of changes, branch out new versions and tag specific versions of the code for easy retrieval. If this sounds confusing don’t worry there is a picture below that explains this a little more.

When we started on Version 2.0 it was easy for the team to work on the code without worrying about tagging, branching and formal release management. Everything we wrote went into a giant bucket known as Version 2.0. While very effective for the initial development that methodology does not work after the launch. When we have to maintain old code while writing new code.

Here’s that picture I promised:

I like using coloured dots to explain things. We have two branches of development, a Maintenance branch (yellow) and a Development branch (red). The green dots in the middle are for Releases, where we tagged the code as stable enough to deploy on the web server.

Having two branches allows us to work more efficiently. We don’t have to wait until Version 2.0 is completely stable and exhausted before beginning work on the next version. We can also add new functionality to Version 2.1 and not worry that it would be included in our Releases before it is ready. This also allows us to work as a team much more effectively. We don’t have to worry about overwriting each others work or destabilizing the code between releases.

The last thing we do is after a maintenance version is stable we tag it as a Release and merge all the fixes into the Development branch. This ensures that our next version includes all of the improvements in the previous version.

When the new version is completed we will tag it as release ready (2.1R), start a new Maintenance branch (2.1.1M) and repeat the cycle. This methodology ensures that released code is always stable, we don’t have to wait to start work on experimental functionality (the fun stuff) and we have the peace of mind that everything is well managed.

[tags]subversion, programming, sutton, source control[/tags]