End-of-Release Branching Strategies

Part 1: Branches and Code Lines

This two-part article explores branching strategies—development tactics that allow teams to work concurrently on different features and maintain the relationship between them. In part one, Steve Berczuk explains what branches are, common types of them, and the tradeoffs between branching styles.

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.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!