Helix Core — version control from Perforce — tracks, manages, and secures changes to all your digital assets, including large binary files. Scale your infrastructure, support your remote teams, and move faster.
Full Video Transcript
The Streams feature enables you to model a variety of development processes and relationships between components of a product. In this video we’ll demonstrate building an effective stream model that reflects how we collaborate on a project as it grows over time.
I’m starting to build out the branching model for a product called Acme. I’ve already made a stream depot and checked in the prototype code in the main stream. Acme has three components or modules. I’m going to create a development stream so my team can work on the first release, code-named lightning. I’ll call this stream dev-lightning, following a simple naming convention of the stream purpose (development) followed by the release code-name. The stream parent is //acme/main, and the parent-child relationship is how we build the stream hierarchy. The stream type is development, which tells us that this stream is less stable than its parent. I’m going to choose the option to have the new stream populated automatically.
Pretty soon the dev lead tells me that she needs a library that’s developed by another part of the company. I’ll use the stream paths to add that. Since I added that to main, it’s also automatically available to dev-lightning, and it will show up (read-only) in any workspaces for the lightning project.
After some time, the team working on lightning is almost done, and so I’ll create a release maintenance stream for their release. I’ll call this stream rel-1.0. For release streams, I know the official release number, so I’ll use that in the name. The stream type is release, which means it’s more stable than its parent, main, and change normally only flows in one direction: bug fixes merged from rel-1.0 to main. We can always override these settings if we need to make an exception; they provide guidance, not rigid structure. Notice as I’m building the model that the stream graph quickly gives me the big picture, showing the different types of work on the project, with the more stable work shown higher in the graph.
At the same time, I want to get ready for the next release, code-named thunder. This will be a bigger effort, so I’m going to split the work into different teams and make an integration stream for them to use. I’m going to split the work into three teams, one for each module. I’ve extended my naming convention to include the specific team or module the stream is meant for. Stream names will help the team find the streams they’re interested in, using the filtering tools. I’m using the stream paths to indicate that, for each stream, one module will be actively developed, and the others are present but read-only (not branched). Anyone working in that stream will get the right set of files.
After some time, the thunder dev manager lets me know that he’s almost ready to ship a beta release. I’m going to make a release stream for thunder. I’m also going to reparent the 1.0 release; any bug fixes found there should merge first to the 2.0 release, then on to main.
Now one of the developers working on thunder’s db module wants a private stream to experiment on a last-minute bug he’s found. I’m going to make that stream and set the access control to make it his own private playground. Note that this stream should be owned by earl. At the moment earl won’t be able to promote work; it’s so late in the dev cycle that his team lead has to approve his changes first.
As our last example, after a few more weeks we realize that there’s a big security flaw in the 2.0 release, which shipped a while back. The fix is complex, so I’ll make a patch branch for the fix.This patch stream is a development type, but that just means that it’s less stable than its parent, rel-2.0. The patch stream has a defined life span – it’s only active as long as the patch is being developed. When the patch is done, it’s merged to rel-2.0. From there we can decide whether to make another release stream, like rel-2.1. Also note that I’ve tried all along to adopt naming conventions that indicate what a stream is used for, to make it easier to find and identify streams of interest. I don’t need to get this right at the first pass; stream names can be changed, and don’t require moving any work to a different directory.
That wraps up our overview of codeline management in streams. Using streams, I’ve been able to quickly build a branch model that reflects how the Acme product is developed and how the teams collaborate on it. The model is strong enough to provide guidance but flexible enough to allow for adaptation over time as the Acme project gets bigger and more complex.
If you’re not sure about what development and release processes are right for you, have a look at Perforce’s codeline management training class. For more information, consult the Perforce Directory Standard or email support at perforce.com.