May 26, 2011

Streams applied: Mainline Development

Branching
Healthcare
Streams

This article is the second in a series introducing streams in the context of concrete use cases. In this article I’ll look at using streams to simplify development and release management work in a traditional software project.

I’ll be working with a software product called Jam, which goes through a very traditional development and release cycle. Those of you who have been through a Perforce training class will recognize Jam, an open source build tool that we use for our sample and training databases.

(Note that the visual tools shown in this article may look different by the time they are generally available.)

Data Model

This project uses a mainline branching model, with development streams to facilitate concurrent development, and release streams for maintenance of older releases. The model is shown below.

Mainline model
Mainline model

As development work reaches stability, it is promoted to the mainline, and a release maintenance stream is created. Bug fixes are merged down from the release stream to the mainline. Other active development streams merge down completed work and bug fixes from the mainline.

The corresponding stream model is shown below.

Stream model
Stream model

Using Streams on the Development Stream

Let’s consider the typical merging activities that happen on an active development stream. I’m working in the role of a project manager for the Jam 2.4 development team, so I’m responsible for merging in new work from the mainline. When the 2.4 effort kicked off, I used the stream graph to create the development stream, seed it from the mainline, and create a workspace – all with a few clicks.

Creating new stream
Creating new stream
New stream dialog
New stream dialog

As development progresses, once or twice a day I pull up the stream graph to check if there are incoming merges from the mainline. These are usually bug fixes from older releases, but once in a while there’s new stable development work to merge.

When I notice a pending merge in the dev2.4 stream, I quickly pull up the merge dialog to complete the merge, pulling in other developers to help me resolve files as necessary.

When my team reaches a stable milestone, I do one last check for any pending merges from the mainline. Next I move my workspace to the mainline in preparation for promoting the development work. That happens quickly; a drag’n’drop starts the process, my workspace view is updated automatically, and the server efficiently updates the contents of my workspace.

Now I promote to the mainline, starting with the context menu and finishing with the promotion dialog.

Now I have a pending changelist with the promoted files, ready to submit.

Using Streams at Release Time

Finally I’m ready to stabilize the 2.4 release of Jam. From the stream graph, I quickly create a new release stream and a corresponding workspace.

During testing, the QA team finds a couple of defects. My team fixes them, and I need to merge those bug fixes back to the mainline to share them with other teams. (And if I forget, the release manager will notice the pending merges on the stream graph and remind me!)

I’ll drag’n’drop my workspace back to the mainline, and merge the bug fixes.

Fast and Productive

Managing a software effort like my simple Jam project has always been easy in Perforce. Using streams gives me an intuitive visualization of the status of the streams, so I know at a glance whether there are pending merges or promotions. Streams also give me quick access to common codeline operations, and let me easily switch to different streams at release time. All in all, a good experience made better!

So far in this series I’ve looked at fairly simple use cases. Coming up soon is an article diving into the use of streams to help with the complexities of Agile development.