November 29, 2016

DevOps Digest 303: Everything You Never Knew You Needed to Know about Streams

DevOps Digest

In DevOps Digest 203 we compared promotion and trunk-based branching strategies, concluding that trunk-based development (TBD) grants us the most freedom and flexibility for rapid release cycles. Today, we take things further and explore the ways streams, a feature unique to Perforce Helix, can help us implement our strategy.  

Streams are a way to codify TBD best practices, ensuring that only the most stable code flows upward, while developers can create any number of streams and child streams to organize teams in whatever ways make sense.

Streams are a superset of branches, offering the usual benefits of branching with additional logic and control. A typical project involves multiple layers of streams.

layers of streams branching strategy

Release streams represent the most stable code, so they’re always at the top. The trunk is the next level down, what in Helix parlance is a “mainline” stream, as it should be the most stable stream regularly receiving work. The idea is to deliver only complete, well-validated units of work to the trunk to ensure that you could (ideally) produce a new release at any moment, merely by creating a new release stream above it (not coincidentally, mirroring our earlier illustration of the TBD branching model).

Streams beneath the trunk, or mainline, subsequently offer you the flexibility to divide teams and work in whatever ways make sense. Versioning guru or not, contributors can leverage the power of branching when using child streams.

In the illustration above, the first level below the trunk might break work up by teams, features, or groups, whereas the next level down is where individual developers can create their own individual working streams and/or task streams to juggle their own units of work. But this isn’t set in stone; create whatever arrangement makes sense for your organization, projects, and personnel. Streams give you the isolation developers expect from lightweight, in-place, local branching, yet they also offer developers the choice of a purely centralized approach, DVCS, or any hybrid combination of the two.

You may recall that we already created a mainline stream and committed our sample project to it. This was a great choice for an individual creating a new project, but as projects and teams grow, you’ll likely find the kind of layered-streams approach to make more sense.

Creating child streams, or streams at a lower level, is easy. For example, if we open the Helix Visual Client and look at the streams for our sample DevOps depot, we need only right click the existing mainline stream and choose “Create New Stream from ‘Main’…” on the context menu. That invokes the new stream dialog:

creating child streams

Notice how the “Stream type” is automatically set to “development” rather than “mainline”. That’s because, by default, Helix knows you’re looking to create a lower-level stream from a mainline. Notice also the options for “Change propagation” below the type. Helix streams let you define and control the flow of code, even restricting the ability to deliver content to certain users/groups if needed. The defaults are already selected for a typical development stream, one that will both receive updates from its parent and ultimately contribute completed work back to its parent.

This is a great feature of streams because it formalizes the best practice of merging down and copying up. Streams enforce this by default and places the burden of integrating work done by others on the individual contributors when they commit new changes. Without gate checks, it is too easy to let unstable code propagate to higher levels and inconvenience others, if not break the build. The time to integrate changes from others is when your own work is still fresh in your mind, not long after you’ve already moved on to other things.

So not only do we choose TBD as our branching strategy, we also leverage the power of Helix streams to enforce TBD best practices by default.

In the next article, we'll finalize our build strategy and automate the debug build for every commit, so stay tuned for Issue 304. 

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 info@perforce.com 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!