Minimizing Bug Fixing Issues Through Branching

It's happening again, a product you've already released needs a bugfix. Sounds easy enough, except for the fact that development has continued in the branch, because of the forthcoming .01 release. Hours are wasted in meetings, conversations and idle thought. Management and developers further complicate the issue through theorizing solutions rather than using existing infrastructure to solve the quandary.

In this article I'll explore both a technique and process to minimize this problem, and a method of solving the existing mess. Most importantly, we will use a tool with which you're already intimately familiar, your revision control system. For a little infrastructure investment, your organization can save hours of headache and frustration, and potentially thousands of dollars in lost man hours.

To begin, let's discuss the process approach. By using a branch with every version, we can minimize future source management and avoid related headaches and costs. Whether your organization branches only at releases or before, the import is the branching of code. Once a shippable version of the product is built, the collection of changes must be labeled. Regardless of whether or not your revision control system supports labeling, the collection of changes (or changeset) must somehow be recorded with a phrase. Attaching a semantic name to a changeset simplifies bug fixes; beyond that, it's simply human nature to remember a name instead of a number.

This is merely the process approach, but it must be equally supported through behavioral engineering. Source control gurus working in this environment need to enforce this rule through their actions. Under no circumstances are changes destined for a new version to integrate into the repository. Accepting changes destined for other versions means that lines of development are no longer properly pure.

Imagine. You've recently released version 2.0 of a product, and development has already continued in the tree for version 2.0.1. Suddenly, there's a need to create a version 2.0 release but the source contains 2.0.1 code as well. Your first instinct might be to manually build a 2.0 with the proper code patches from your revision control system. After all, the changes are checked in, right?

Unfortunately, this isn't the problem being solved. Creating this ad hoc build merely introduces mass instability into your environment. More importantly that release can never be accurately reproduced or bug fixed. And of course, while management has indicated that this change is the "last of the line", as source control professionals we neither care nor believe it to be true (and in fact it never is).

Instead, let us imagine that you've branched the source code and labeled it accordingly. This combination of labels and branches makes reverting to known changes simple. Want to rebuild your original release, just clone your repository to the specified label! Need the specific version of a release, just clone the proper source area! Bug fixes are a snap, just clone your source and patch the area needed.

As obvious as these ideas are, they tend to take a beating in organizations when multiple platforms are required for a product. In these environments, a product is frequently released, seemingly complete, on all platforms when the reality is that only one target platform passes a quality assurance sweep.

These special (though frequent) cases require a multi-label effect for a given codeline. The first label should be applied to the product that shipped, and the next (and semantically different) label is applied to the newly released repository state.

While the combination approach of branching and labeling won't eliminate bugs due to versioning, it will help minimize them. Following these steps can ensure that quality software can be released, and patch builds can be made from an accepted point in time. The consequences of not following the branch and tag methodology lie chiefly in an inability to reproducibly produce quality software of a known quantity. Personally, I'd rather get it right the first time.