CLM configuration management: Multistream concurrent release development strategy

Todd Dunnavant, Ph.D., P.E., IBM
Last updated: 13 November 2017
Build basis: IBM Collaborative Lifecycle Management Solution (CLM) 6.0.4 or later, IBM IoT Continuous Engineering (CE) Solution 6.0.4 or later

This article is part of a series that provides guidance for planning configuration management for the IoT CE solution.

Introduction

This article explores patterns of stream usage for situations where you work on multiple releases of a product concurrently. Many organizations find these patterns useful on their own. These patterns also form the basis of the more complex multistream variant patterns, as explained in the Multistream variant strategy article.

Many patterns are introduced in the companion Patterns for stream usage article. That article in turn points to the other stream details articles in this series. We suggest you read about the more basic patterns, such as the single stream strategy, before you read the current article.

The patterns we present here are relatively complex. If an opportunity to “go simpler” presents itself, even for a single component, we encourage you to do so. For example, if you can build and maintain a reusable component of regulatory requirements using a single-stream pattern, rather than one of the multistream patterns, by all means use the simpler pattern.

In this article:

We begin by presenting and discussing the motivations for these patterns and some of their common characteristics.

We then describe the structure and applicability of two stream patterns:
- Branch from previous release; for example, having the Release 4 stream branch from the Release 3 stream; and
- Branch from main product branch; for example, having the Release 4 stream branch from Product Main.

We illustrate and discuss these patterns using example stream-and-baseline trees of local configuration. Version history graphs for global configurations (GCs) can have similar visual characteristics.

We then address how teams that use each of these two stream patterns might evolve global configurations.
We end by presenting an undesirable variation of the second stream pattern. We provide this antipattern and explain why it is unhelpful so you can see how innocuous-appearing aspects of a streaming model can have cascading negative effects on the development team.

Choosing the right pattern

Simple patterns for sequential releases include:

Single-stream sequential release.
Multistream promotion, where teams work on a single release at a time in one release stream and one development stream. This pattern eases a number of issues with the single-stream sequential release pattern.
Multistream maintenance, where all development is done on the product’s single sequential release stream, and maintenance streams are branched for each release.

However, none of these patterns support concurrent development of multiple releases. If your organization needs to work on multiple releases of a given product or component at the same time, consider one of the development patterns for multistream concurrent releases in this article.

Future articles in this series will discuss the multistream promotion and multistream maintenance patterns.

Common characteristics of multistream concurrent release patterns

The two multistream concurrent release patterns share several aspects:

Each release stream is its own production stream.
Multiple releases can be in production and be supported at any given time.
Maintenance is ideally done directly in the release stream. Overlapping or parallel fix work on a given release might require multiple maintenance branches off that release branch.
Teams should baseline their release streams at significant milestones such as releases, fix packs, and especially before accepting delivery from another stream.
Teams should expect that eventually a release will come to end of life. Some of the patterns enable archiving of the stream, along with all its baselines.
Stream hierarchy can differ across technical domains. For example, source code management (SCM) is likely to have a rigorously-defined stream hierarchy as part of a promotion-and-test lifecycle model. QM and SCM are more likely to require maintenance fixes than RM.

Multistream concurrent release development patterns

In this section, we address the patterns at the level of local (that is, single-tool) configurations. Later, we discuss maintaining global configurations that are based on these patterns.

Pattern 1: Branch from previous release

Here is how you work with this pattern:

When work on a new release is ready to begin, branch a stream for the new release from the most recently created release stream.
Baseline at milestones, such as before you create new release branches, and for general availability or fix pack releases.
Deliver updates down through the stream hierarchy during development.
Maintain a given release directly in its release stream (there are no separate maintenance streams).
- Because each release is managed in its own stream, after you deliver “to production” and create a baseline, you can do maintenance directly in the stream. Each maintenance release is sequential and builds on the previous one.
- If you need to work concurrently on several maintenance streams for the same release, you branch another stream from an appropriate baseline of the release stream, and deliver back to the main stream when your work is complete.
Where needed, deliver fixes up the hierarchy, for example, from the Release 2 stream to the Release 1 stream.

The following diagram shows how this pattern works:

This pattern has these benefits:

It is simple.
All work for Release N is done in the Release N stream.
Release streams are clearly identified.

However, you can’t archive older streams until the entire stream hierarchy is ready to be retired, because you can’t archive a stream if it has active child configurations.

The simplicity of this pattern is appealing. It’s easy for teams to use successfully, particularly when you don’t anticipate the need to archive older streams. If you will be producing so many releases that you might want to archive your older streams, you should use the next pattern.

Pattern 2: Branch from main product branch

In this pattern, the main or trunk is the source of all the release branches. Here’s how you work with this pattern:

Create a branch for Release N as soon as work can begin on Release N.
To start the new (N) branch, deliver from the previous (N-1) branch to the Main stream. Then, branch the new Release N stream from Main.
Deliver to the Main stream only from the latest Release branch.
Deliver changes from older release branches down through the hierarchy.
Do maintenance directly on the release streams.
The delivery path of fixes is same as the path for other changes:
- Down the hierarchy from an older release stream to a newer release stream
- Up from the newest release stream to the main stream
- Down from the main stream to older release streams

This diagram shows how this pattern works:

This pattern has these benefits:

All the work for Release N is done in the Release N stream.
You can archive completed streams.
You can easily identify release streams.

However, this pattern has a more complex cross-stream delivery model than pattern 1, where you branch from the previous release.

The delivery model for this pattern might be confusing until team members get used to it. But the ability to archive completed streams can be very useful.

Global configuration scenarios

Now, add global configurations to these patterns. For simplicity, the global configuration hierarchy in the following scenarios shows only one component. In reality, the global configuration hierarchy for a significant product or application probably contains tens to hundreds of global configurations, with each global configuration aggregating the local configurations that are needed to define or implement a specific component of the solution. Read more about more complex global configuration hierarchies in the Defining your component strategy and Multistream variant strategy articles in this series.

Global configuration using “Branch from previous release” local configuration pattern

This is a straightforward global configuration (GC) evolution model. The following diagram illustrates the conceptual stream network for the local branching model and conceptual changes as the GC hierarchy evolves.

Keep in mind that the associated local configuration management pattern has an issue in that you can’t archive earlier streams until work on all later streams is completed.

In this diagram, the abbreviations stand for the application that contributes a stream or baseline:

RM = Requirements Management — local configuration managed by Rational DOORS Next Generation
DM = Design Management — local configuration managed by Rational Design Manager
QM = Quality Management — local configuration managed by Rational Quality Manager
CCM = Change and Configuration Management — code stream managed by Rational Team Concert (RTC) source control management (SCM)

In this scenario:

Multiple teams begin work on Release 1, with all teams working in their streams (#1 in the diagram).
The RM Component A team, for example, finishes their Release 1 work and is ready to start work on Release 2.
To prepare for the RM Component A team moving to Release 2, all teams deliver their most current work to their Release 1 stream. They create a new baseline for all their streams. The GC administrator creates a new Release 1 GC baseline (with a meaningful name) (#2 in the diagram).
Depending on organizational process, the RM Component A team might replace their stream in the Release 1 GC stream with their just created Release 1 local baseline. Doing so isolates the other teams from any changes in Component A, whether inadvertent or for exploration, change, or impact analysis.
The GC administrator creates a Release 2 GC stream from the Release 1 GC baseline they created in step 3.
The RM Component A team creates a Release 2 local stream from their Release 1 local baseline. The GC administrator replaces their baseline in the Release 2 GC stream with this local stream (#3 in the diagram).
Each team repeats steps 3, 4, and 6 as they complete their Release 1 work and begin their Release 2 work.
After all teams finish work on Release 1, the GC administrator creates a release baseline from the Release 1 GC stream. Further changes in the Release 1 GC stream are considered “maintenance”. If all the local contributions to the Release 2 GC stream are now streams, these maintenance changes can be delivered to the Release 2 GC stream using the GCM application, rather that the local applications.

You might need to add or change those steps so that the workflow meets your needs. Here are some common variations:

Additional work needed in Release 1: Suppose that, in step 4, the RM Component A team replaced their Release 1 local stream in the Release 1 GC stream with a Release 1 local baseline. If that team needs to do more work on Release 1, they follow this workflow:
1. The team replaces their local baseline in the Release 1 GC stream with their Release 1 local stream.
2. The involved team members switch from the Release 2 GC stream context, back to the Release 1 GC stream context, and make their changes.
3. When they finish their changes, the team:
  1. Delivers their Release 1 local stream changes to the local streams of their later releases, such as Release 2.
  2. Creates a new Release 1 local baseline.
  3. Replaces their local stream in the Release 1 GC stream with their just-created Release 1 local baseline.
  4. Switches back to the current release context and continues work there.
Need to see more current work from other teams, in the Release 2 GC. Here, the RM Component A team is working on Release 2, and they need to see the latest work from the other teams who haven’t yet transitioned to the Release 2 GC. They can use one of these approaches:
- Work with the GC administrator to replace the current local baselines in the Release 2 GC with baselines based on the other teams’ current Release 1 work. This can be done using the Global Configuration Management (GCM) application’s Update function.
- Use the capabilities of the engineering tools, such as DOORS Next Generation, to compare specific configurations, such as another team’s current Release 1 stream and their baseline that is associated with the Release 2 GC.
Need to create Release 3 before Release 1 is complete.
1. Baseline the most current Release 1 work.
2. Use the GCM application’s Update function to replace any Release 1 baseline contributions in the Release 2 GC with the latest Release 1 baselines. The contributions that are replaced are not necessarily just local baseline updates. They might be lower level global baselines that represent the update of an entire subtree of configurations for a component.
3. Baseline the Release 2 GC.
4. Branch the Release 3 GC from the Release 2 GC baseline.

Global configuration using “Branch from main product branch” local configuration pattern

The following diagram illustrates the conceptual stream network for the local branching model and conceptual changes as the GC hierarchy evolves.

In this scenario:

Begin with an empty GC Main stream (#1 in the diagram).
Baseline the GC Main stream and branch a Release 1 GC, including Release 1 local streams (#2 and #3 in the diagram).
Deliver changes to the GC Main local streams periodically.
When the RM Component A team, for example, completes their Release 1 work and is ready to move on to Release 2, they baseline their work and deliver their changes to their Main stream.
In preparation for the RM team moving to Release 2, all other teams deliver their current work to their Main local streams.
The GC administrator takes a global baseline of GC Main, reflecting each team’s most current work (#4 in the diagram).
The GC administrator branches the just taken global baseline of GC Main to create the Release 2 GC stream (#5 in the diagram). Initially, all local configurations remain the baselines created in step 6 (#4 in the diagram).
The RM Component A team branches from their Main branch to create a Release 2 local stream. The GC administrator replaces their baseline in the Release 2 GC stream with this local stream (#6 in the diagram).
As each subsequent team finishes their Release 1 work and prepares to move to Release 2, they repeat steps 4, 5, 6, and 8.

Overall, the GC workflow for this option is similar to the previous GC workflow, with the addition of the Main stream as the stream from which new Release branches are made. You can use the common variations of the previous workflow, as well. The main difference is that changes are delivered to the Main branch of each local configuration before branching a new release, rather than delivering all changes to the most current release stream before branching a new release.

An antipattern: Just-in-time branching from the main product branch

We have encountered a variation of pattern 2, “Branch from the main product branch”, which we consider to be an antipattern. Remember, in pattern 2, a new branch for Release N was created as soon as work began on it. This antipattern works a bit differently.

The branch for Release N is not created until work on Release N+1 is about to start (Pattern 2 creates a branch for Release N as soon as Release N work begins).
After creating the Release N branch, Release N work continues on this new branch.
After creating the Release N branch, Release N+1 work continues in the Main branch (in Pattern 2, current work always happens in release branches).
Updates are delivered from branched releases to the Main stream, so that current work picks up these changes (Pattern 2 delivers down the branch hierarchy).
Maintenance is done directly in the release streams.
Fixes are delivered to the Main stream and pulled down to the lower streams as needed (this is simpler than Pattern 2).

The following diagram illustrates this pattern using local configurations:

Just as with the previous Pattern 2, the antipattern enables archiving of completed streams, because the individual release streams don’t have their own branched streams.

The delivery model for this pattern actually is simpler than is the Pattern 2 model. Here, all fixes from all release streams go back to the main stream and then are pulled down as needed. This is about as simple a delivery model as can be conceived!

So, why do we consider this to be an anti-pattern?

It’s because of the confusion and administrative overhead that can result from using this pattern.

Let’s say that I’m starting my project and I’m working on Release 1. The GC administrator created a global context for my team to work in, let’s call it Current Release (Main). Now, one of the teams we are collaborating with finishes their Release 1 work, causing a GC branch for all the rest of us. We need to switch from the Current Release (Main) GC to a new Release 1 GC, even though we haven’t started working on a new release! Not everyone will make the switch successfully, resulting in some content creation errors. Additional aspects of my team’s tools also need to be reconfigured in mid-release, such as (1) the Rational Team Concert mappings that are used to “glue together” our GC and our work items, (2) our dashboard widgets, and (3) our reports, because of the context switch that is caused by using this particular stream pattern.

You might choose to use this pattern, if you think that its simple delivery model is compelling. Just be aware that using it leads to a very clumsy context-switch in the middle of your project. This switch can result in staff losing track of which context they should be working in and administrators doing substantial reconfiguration of tools.

Summary

Large-scale software and product development commonly has teams working on many releases at the same time. To perform effectively under such circumstances, teams must be able to start each release with the proper artifact versions, evolve their release artifacts without pollution from extraneous changes, and share their changes with others when it is appropriate to do so. This is as true for lifecycle artifacts, such as requirements and test cases, as it is for source code.

We have described two branch management patterns — (1) branch from previous release and (2) branch from main product branch — to help manage multistream concurrent release development. Each pattern has pros and cons and is better under certain circumstances. Overall, the more generally applicable pattern is to branch from the main product branch. You can implement each pattern with the IBM CLM and CE solutions.

The IBM CLM and CE solutions provide global configurations to manage the hierarchies of multidomain lifecycle artifacts that support the development of each release. In this article, you saw how to evolve GCs when either of the patterns is used to manage the local configurations that contribute to the GCs.

Finally, we presented a multistream management antipattern. At first glance, this antipattern appears to be similar to the preferred “branch from the main product branch” pattern. However, our analysis of the antipattern shows how some seemingly minor differences in your branch management strategy could have a significant negative impact on team performance.

For more information

See the other articles in this series:

Contact Tim Feeney at tfeeney@us.ibm.com or Kathryn Fryer at fryerk@ca.ibm.com.

You can find details about these topics in IBM Knowledge Center:

Using change sets (where supported), see Managing changes to artifacts
Using change sets, see Working with multiple change sets
Delivering changes between local RM streams, see Delivering change sets to other streams
Delivering changes between local QM streams, see Comparing and merging test artifacts

About the author

Todd Dunnavant, Ph.D., P.E., is a Principal Solution Architect with IBM Watson IoT Services. He has 20 years experience in successfully transforming how software, systems, and product engineering teams work. For the past six years, Todd has focused on realizing these transformations using IBM’s Jazz-based products. More recently, Todd has helped multiple product-centric companies adopt the lifecycle configuration management capabilities of the IBM IoT CE tool suite. He can be contacted at twdunnav@us.ibm.com.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Feedback

Was this information helpful?

Yes

No 1 person rated this as helpful.