Choosing a way of Branching

Main Line (or Trunk-Based) development is often the best choice for most teams. But not every group. Here are some factors to consider when choosing a branching model.

An effective branching model is aligned with the goals of your delivery process, in particular, key attributes such as:

• Time to Delivery: models with more staging and integration branches mean longer delivery times.

• Number of Concurrent releases you want to support: Some models emphasize supporting parallel releases, while others focus on always delivering from the Main Line and prioritizing one active release.

• Risk Management approach, from more validation to faster integration: This is often, though not always, associated with the degree of automation a team uses to deliver and test.

• Contributor Dynamic: different developer communities have different dynamics and needs. Approaches that focus on faster delivery need groups with more collaboration and communication and can more easily support more rapid integration. Models with more staging favor more isolated groups, such as open-source projects or teams that try to do more parallel work, or which are more siloed.

In any branching model, there can be exceptions. For example, with a Main Line approach, you will often deliver from the HEAD of the main line and never branch on a release. But there may be rare exceptions where a hotfix makes sense. The question is whether the “exceptions” are truly rare events.

Of all these attributes, Risk Management (or how teams perceive it) is a major force in selecting an approach.

Risk Management

There is a tendency to try moving slowly to mitigate risk: moving slowly seems safer, as you can add more verification steps. And moving slowly seems to give you more control. This can be true in limited circumstances, but in the case of team software development, this is really an illusion of control:

• The longer the integration process, the larger the typical unit of work is. This makes testing (and fixing errors) longer and more complex. This complexity can add additional delays.

• Longer delays lead to greater business risk, such as not delivering features when they add value and not delivering fixes promptly.

With Main Line development is that rapid integration is the way to mitigate risk by:

• identifying errors quickly

  • being able to deliver fixes rapidly

  • having a robust rollback strategy in cases where a fix can’t be delivered quickly enough.

With a minimal number of supported releases (typically 1), you lower the support overhead on the team.

More than Branching

Using a branching model that favors rapid integration, like the Main Line, means;

• Development starts off the Main Line.

• You release from the HEAD of the Main Line

• Code changes got back to the Main Line quickly.

• Minimal Branching:

  • Short-lived task branches.

  • Limit the use of Transient Release Lines to support hotfixes

Working effectively with a branching model that favors rapid integration involves more than defining a workflow and asserting that you will use it. You need to have:

• A Development process that supported automation and testing

• A Planning process that supports incremental delivery

• An Architecture that supports hidden delivery/deployment of work in the process

• A management culture that supports collaboration towards shared goals rather than individual metrics

Implementing a Main Line workflow without these things in place could be a way to identify the gaps in your process if you are willing to address them. And it’s often better to move towards faster integration, than wait for underlying elements to be in place: the codeline model will help you identify issues.

Alternatives

While Main Line development is the right choice for many team software development contexts, it’s not a fit for every situation.

• Open Source projects (or an internal variant of these) might work better with Git Flow. But consider whether your internal project can’t be structured with a more lightweight process

• A staged branching model, like Github Flow or Feature Branching might be an incremental step as you build out the supporting elements of the process ecosystem, but it can be easy to become complacent.

• A Release Train makes sense for some teams that don’t release continuously for customer or compliance reasons, but you need to be mindful of the time you spend fixing code that has been identified for release v delivering from the HEAD of a component’s code line.

If you are working in a team environment with a shared goal, it’s worth considering how to shift to using a branching model that facilitates collaboration and delivery. This includes making process changes to support that collaboration.

Aside: It’s worth noting that what I’m referring to as Main Line development is structurally similar to Trunk Based Development. The reason I’m making a distinction is that Main Line development adds an emphasis on the elements of the development environment that support rapid delivery.