Home | All Posts

[01 May 2011] Avoid Preemptive Branching

I really like this blog post on the dangers of preemptive branching. It basically points out that the act of branching for a release candidate should be performed as late as possible (if at all) and that the hardening process should utilize the entire team. This approach helps to avoid a series of problems which will hamper the project and the team with complexity and sub-optimal conditions. In the end, rather than getting value from splitting team effort, a preemptive branch actually diminishes the ability of the team to deliver. Some of the ugly results will be decreases in code quality, over-specialization and knowledge centralization of individual team members, general failure to meet the goals that the branch was supposed to help solve in the first place, increased technical debt, and overall reduction in agility.

The author lists a number of reasons why preemptive branching is problematic. I find this one to be quite damaging:

Increases the work-in-progress and creates a lot of planning, management, version-control, testing, etc. overheads.

The daily challenge of playing traffic cop to a team of committers under pressure to be “done” can be quite time consuming and frustrating. Consider some of the annoyances:

  • Every individual on the team needs to understand where they need to do their work. You might have a hardening team working in the release branch, but there is a good chance that these team members are also the “most trusted and knowledgeable” members of your team. As such, there will be cases where they will be needed to split their time between the release branch and mainline. While what needs to be communicated is typically simple (eg. Bug Fix A goes in mainline and Bug Fix B goes in the release branch), doing it in an effective way requires process and takes time.
  • Even if the team has overcome the hardship above, there is always the inevitable realization that a change that went to mainline was something that the release branch depended on for hardening. Those changes then need to be recreated manually in the release branch, which inevitably create merge conflicts when going back to mainline.
  • The longer a release branch lives, the greater the chance that the merge path among branches can become complex or in the worst case impossible.

In addition to the reasoning of the author against a preemptive branch, I also see the following risks:

  • All the merging and branching strategy that I describe above can easily become overly centralized such that only one person knows what is going on in source control.
  • The goal of just hardening a release is sometimes lost the longer the release branch exists. As the release remains in hardening mode past its expected delivery date, the demand for additional features promised can pressure the team into sneaking some of those features into the release branch.
  • The release branch may fail to ever truly harden. This failure could be a result of the previously described feature-sneak, but may also be the result of too much technical debt.
  • The sum negative impact of a preemptive branch chips away at the team’s agility.

I can’t seem to think of any easy ways out of a release branch started too early, especially once the project is weakened by several cycles of this type of branching. Preventing future preemptive release branches is likely the best thing to do, though that may only be possible after accepting delays in the release schedule.

Home | All Posts