End-of-release Branching Strategies

With meticulous application of agile testing and release-management principles, it is possible to avoid a long, end-of-release period by realizing the goal of a shippable product at the end of every iteration. Many teams have not yet attained this level of discipline, and proper use of code branching can help a team make progress. However, using branching incorrectly can have the undesired effect of slowing down rather than speeding up the team's progress.

In this article we'll describe what branches are for, and how to understand tradeoffs between branching styles. In part two, we will discuss three approaches for managing the end game of a release cycle and explain how to finish a release when you're not quite agile enough to always have ready-to-ship code.

Code Lines and Release Branches
A code line is a stream of development to which developers commit changes to be shared with other members of the team. Development starts on a single code line. As time passes, the team may decide that a section of the code needs to evolve in parallel with the main stream of development. When this happens, the team creates a branch.

A branch is simply a parallel stream of development work that starts from another code line. In effect, to branch is to make a copy of the code at a specific point in time so that the code can evolve independently. Source code management (SCM) tools can simplify the process of merging changes between two code lines by keeping track of what changed in each code line since the time of the branch. Figure 1 is an example of a simple branching diagram.

Figure 1: Branching

A branch has two important attributes:

1. The point in time that the branch was created. This is captured by the version management tool's ability to track ancestry and is used to manage the mechanics of merging.
2. The reason you branched. This is often captured with naming conventions or metadata and is used to determine how to work with the code line and the process to follow before committing changes to the code line

While the mechanics of branching are the same, it is the reason for the branch-often associated with a policy to apply when committing code to that branch-that makes each branch special. Among the most commonly-used branch types are:

• Release branches-used to maintain code released externally
• Task branches-used to allow collaboration among team members for long-lived tasks without accidentally breaking code for others
• Private branches-used to allow an individual developer to use the features and benefits of the code while doing risky or experimental work

<div=align left="">Figure 2 (see below) shows a common, simple code line structure: main line development. The simplest code line structure is a main line model where a team works primarily on one development line, the main line. The advantage of the main line model is that it is simple; there is a single point of integration, and it's easy to determine the current state of the project without looking across code lines. The risk with a single code line is that broken code that's committed to the main line can cause everyone problems when other developers update with broken code in the workspace. How you address the risk of this kind of breakage gets to the core of your development philosophy. You can assume that things will break and isolate work so that you can fix problems offline, or you can work towards a process where you keep your code working.

To balance the problems that could be caused by careless commits with the benefits