November 15, 2016

DevOps Digest 302: Considering an Effective Branching Strategy


DevOps Digest Issue 302 image

Now that the build process works nicely in Jenkins, our next step is automating it, but this requires some thought. It’s easy enough to establish simple source control polling to execute our current job whenever Jenkins detects changes in Perforce Helix. We could even make it event driven by establishing a trigger on the Perforce Helix server to launch the build in Jenkins.

But what do we really want to build automatically?

If simple continuous integration (CI) is all you care about, you’re good to go. But for a more substantive, sophisticated DevOps pipeline, one that keeps all stakeholders happy, it’s time to think about our branching strategy.

Ideally developers, other content contributors, quality assurance (QA), and others should each have their own working area to avoid chaos and confusion. For example, QA often involves manual processes and your QA engineers will not appreciate when developers deliver a whole new release candidate (RC) while they’re still testing the last one.

This is why smart teams choose a branching model that fits the shape of their organization. An entire series of articles could be written on this topic (check out the branching category on the Perforce blog), so we’re going to keep it simple here and highlight the two more common models: promotion and trunk-based development (TBD). The following illustration is a promotion branching model.

promotion development model

Key to this model is that the last release becomes the springboard for work to begin on the next release. In other words, if the most recent release is on a branch named “R2”, then the next release is branched from that and named “R3”, said branching usually being performed when R2 is released. This allows most stakeholders to begin working the R3 branch immediately, while a smaller subset deal with any issues in the R2 release on its old branch.

The down side is that any fixes subsequently made in R2 have to be cherry-picked to roll that work forward into R3. Even worse is the need to backport new features under development in R3 to the R2 release. Both of these can be painful, manual processes, which are effectively the trade-off for otherwise enabling teams to potentially work on many releases at the same time in decent isolation with the promotion model. Contrast this with the trunk-based development model.

trunk based development model

The difference is that the project’s “trunk” becomes a never-ending line into the future from which releases are taken. The main point of contrast is that in the promotion model, the next working branch eventually represents the release, whereas the trunk is the working branch from which the next release is branched. None of this addresses the strategy for other “development branches,” be they for teams, feature areas, or even the most lightweight of tasks, but hopefully the basic differences between the two more common models are clear.

Perforce has long advocated the TBD model because we believe it offers greater flexibility in breaking down work among teams, managing stability (particularly, with streams), and regularly and rapidly integrating work from others.

If nothing else, the promotion model tends to delay release branching, which can lead to friction with stakeholders whose work for the current release is completed and are waiting to move on to the next thing. In contrast, TBD lets stakeholders keep working more easily, so that’s what we’ll be using for our sample project going forward.

In our next issue, we’ll supercharge our branching strategy with powerful streams features in Perforce Helix. We're taking a break for Thanksgiving next week, but stay tuned for our return on Tuesday, Noember 29.

You Ask, We Answer

As previously mentioned, this is your roadmap to creating a successful DevOps pipeline. Don’t understand something? Just ask. Need to dive a little deeper? Send an email to [email protected] with your questions. Then, stay tuned for a live Q&A webinar at the end of this series. Get DevOps Digest Sent to your Inbox

You don’t need to remember to check back with us each week. Instead, get the digest delivered directly to your inbox. Subscribe to our 25-week DevOps Digest and we’ll get you where you need to go, one email at a time.

See Perforce Helix in Action!

Join us for a live demo every other Tuesday and see the best of Perforce Helix in 20 minutes. Save your spot!