Branching Strategy for Agile Releases with Subversion

The point of source control and other configuration management tools is to not only not get in the way of getting things done, but to enable more parallelism on a software team. A lot of times we (technologists, err geeks) can get caught up in tool selection, modification, and hyper-configuration.

A solution that seems to be working well for the small agile team I am apart of now is a simple version of the traditional promotion model. Instead of a Dev/Test/Production set of branches we simply use Dev/Production for the two long lived branches and feature branches off of Dev for anything that we think might take more than a day or two to implement and stabilize.

Subversion doesn't have merge tracking, yet, but there is a tool called svnmerge.py that makes it a breeze to keep branches updated with changes that have been committed to Dev or Production so that integration from Feature branches back to Dev or releasing from Dev to Production is more fluid and less prone to merge conflicts.

As a general rule, hot fixes are done in the Production branch and then merged back to Dev after releasing. Feature branches are updated with changes committed to Dev at least once a day, sometimes more. We typically release very frequently so the delta between Dev and Production is usually pretty small. Since there isn't any installed software that we distribute (all server based), we have to maintain any release branches, in fact, our versioning is simply the Subversion revision number.