Source Code Version Control

One area of concern that I come up against quite often is the issue of source code version control. At its most basic layer this is nothing more than being able to control what a version of your software consists of... version A versus version B, that sort of thing. This model works great and is well documented on smaller isolated applications but tends to blur a little when working with larger systems. Specifically we’ve had issues managing system dependencies, as well as change requirements on a larger application consisting of about roughly 50 assemblies. I’ll spend just a few minutes here putting pen to paper on how we’ve structured our development tree to accommodate this.

We’ll start at a pretty simple level; each major release is placed in a named folder based on the version name. Our first branch within that folder is named Major.Minor.Zero, Major and Minor are related to the version name while the Zero indicated this is the opening development branch. Here’s how that looks when we start a new major release... our friendly version name is Jupiler and the Major.Minor associated with this is 5.1.

Notice that within the 5.1.0 folder we have a number of sub-folders. These are what we call modules and basically relate to a VS.Net solution; each one consists of roughly 5-6 projects and can be thought of as a sub-system. These sub-systems collaborate to provide our applications functionality.

Now, when we release our major version, Jupiler, we’ll typically LOCK the 5.1.0 folder so that no further changes can be made. This code is set in stone and we want to force all new changes to be done in an isolated environment until they’re tested and ready to go. Invariable though, something critical comes up during rollout and we need to make code changes to address those concerns. When this situation arises we BRANCH into a new folder called Major.Minor.One. This code folder consists of all the new development changes required to add what we call a Service Pack to the release. Here’s how this looks.  

One interesting aspect of this layout is that we only branch the modules that require changes. These Service Pack’s generally don’t require a lot of wholesale change; they`re usually small isolated bugs/features which can be addressed in a single module. You can see in the above diagram that our 5.1.1 only has changes for Accounting, all the other modules are identical to how they were developed in 5.1.0. This gives us a few key benefits.

1.       It limits the amount of open source code.

2.       It makes it easier to identify what code is actively being changed for a service pack.

3.       It leaves the original branch open so that it can be reviewed/modified for OTHER unanticipated issues.

Final rollout of the new changes is done by releasing 5.1.1 of Accounting with all the previous versions of the other modules.