How to manage a single branch

Question

I read the Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation book by Jez Humble and David Farley. The part that throw me off balance the most was their insistence on using a single branch.

Thinking about it and what they are preaching, it does make sense. But the question is, how to achieve it?.

At my company we are working on C# with TFS as our source control. And the following ideas came to my mind about how to achieve the idea of doing changes that you don't want to release yet, but you want to keep inside the vcs tool:

• Injections to be able to select the class that you want to use. So you can rewrite some functionality without affecting code that needs to be released.

• Related, an IoC container to make the above easy to achieve. So you can select at compilation (or even runtime) the ones that you want to use.

• Decorator pattern to add functionality in a very simple manner (which is just applying the other two above)

At another similar question they talk about the Release Line from Software Configuration Management Patterns (which I still have to read). But the example that they are using deals with tags and creation of branches from them, which doesn't seem to be the same thing as what Humble and Farley talk about.

1. Do the techniques that I have described sound right for achieving a single branch strategy?
2. Is there anything else that could be done to manage having your code on a single branch?

Answer 1

Multiple developer branches work just as well as a single branch - better in many cases. You might need to use a better tool for the job that TFS, but now it has git backing it that should do fine.

I would not attempt to change the software architecture to suit your build process, its the wrong approach - the software is the thing that matters, keeping it easily maintainable is much more important than suiting some process that is there to serve the software (not the other way round)

The trick with branches is to merge them into the trunk as soon as possible, and not to branch off new work until they are really needed. The other thing to do is to reverse-merge the trunk onto your branches (ie as changes from branches are merged onto trunk, developers working on their branches need to merge these changes to their branch, so they are very closely up to date) Then merging a branch to trunk becomes a trivial task.

Even with code that will sit around an not be merged for a long time, this is still ok - what it does mean is that the merge will become harder to accomplish as time goes on, but no amount of architectural changes to your code will help here - someone makes a change to the codebase and a year later you decide you need that code... I guarantee it won't work properly without manual intervention and refactoring of the code into what the trunk now looks like. What you need to do with this old code is a 3-way diff, so you can see the changes that were made to the original code, and apply those changes (or the important parts of them) to the new branch. Think of bringing the old code to the new as a development task rather than a build manager merging task.