CLM configuration management: Single stream strategy

Ian Compton, Persistent Systems
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

Use the single stream pattern for basic change management that’s only in a single domain application (that is, requirements or tests or designs). Typically you use this pattern with the Requirements Management (RM) or Design Management (DM) applications, because many quality teams do not have the same motivation for tightly-controlled change.

As described in the Patterns for stream usage article, you can follow different patterns to implement streams. This article explains the simplest stream strategy, which is to have a single stream for each component. At defined intervals, you create a baseline and then continue to work in the same stream.

This pattern assumes that all practitioners work on a single release at the same time, and on the same cadence – that is, they don’t do parallel development. If you have the notion of “cutting over” to a new release, or if some teams work across multiple releases, you need a multi-stream approach instead.

The single stream pattern is specific to single domains. As soon as you introduce multiple domains, it becomes highly unlikely that your team all works on the same timeline, because one domain is usually the driver and working ahead of the others, requiring a multi-stream approach. The exception is if you are using the Rational Team Concert (RTC) application for change management of your other domain streams. You link from work items, such as change requests in RTC, to artifacts in your domain application stream, such as change sets in RM or DM. However, because work items in RTC are not versioned, you still use only a single stream in your other domain application.

In this article, the following application names stand for these products:

• RM = Requirements Management — local configurations managed by Rational DOORS Next Generation 
• DM = Design Management — local configurations managed by Rational Design Manager
• AM = Architecture Management — local configurations managed by Rhapsody Model Manager
• QM = Quality Management — local configurations managed by Rational Quality Manager
• CCM = Change and Configuration Management — code streams managed by RTC source control management (SCM)
  
• GCM = Global Configuration Management — global configuration application

Variations

Choose a variation of this pattern based on your situation.

Single stream – single component

If you are working in a single application domain, and only have only a single stream for a single component, you do not need to use global configurations (GC).

Single stream – multiple components

If you want to subdivide a project area into multiple components that are linked (in one or more project areas), you need a global configuration. Each component then has its own set of streams and baselines.

Single stream – single component, with RTC change management

If you want to link versioned artifacts in your application to RTC work items, you need a global configuration. You also need to configure RTC so it can correctly resolve the configuration context. For more information see this topic in IBM Knowledge Center: Enabling linking of work items to versioned artifacts.

Without a global configuration, you can still link between RTC work items and versioned artifacts, but these links will always resolve to the default, initial stream, which in this case is the only stream. This is not a recommended usage pattern, because if you go back to look at work items from a previous release, the links resolve to the current version of the artifact, rather than the baselined version that is associated with that previous release. Conversely, the baselined artifact doesn’t show the links to the work item. Thus, you can only avoid using a global configuration if you just care about the links in the current stream and not in the baselines. If you want to see the correct links in the release baselines, then you do need a global configuration.

Note for administrators: If you do need global configurations, you will need a Global Configuration Management (GCM) application server. You’ll also need a Link Index Provider (LDX) application server, so that you can see incoming links from other artifacts in a global configuration. For more information see this topic in IBM Knowledge Center: Links across project areas after enabling configuration management. In fact, whether or not you need global configurations initially, you should still install the GCM and LDX applications. Install them because as you evolve your implementation, you are likely to need them at a later time. It will not be too much overhead to install them from the beginning. These applications are not heavyweight, especially if you don’t use them.

Stream strategy

The teams make all their changes to a single main stream in the application. Teams can make changes in parallel, but they are all made to the same stream. In RM and DM, teams can use separate change sets to temporarily isolate changes from the main stream, but all change sets are delivered to the main stream. Resource locking can be used outside of, or as part of, change sets.

When you create your component, the system creates an initial stream for you, also called the “default stream”. In a single stream strategy, you could continue to use this initial stream indefinitely. If you never branch to create another stream, all your work in that project area would be in the default stream.

Other possible stream strategies involve multiple streams to support other patterns such as promotion and parallel development. See the Patterns for stream usage article for more details. You should always pick the simplest stream strategy that meets your needs.

Baseline strategy

When to take baselines: Take baselines of the component in the local application and of the global configuration in GCM, if you are using it. You need baselines at important points in your cycle, at least at milestones or release boundaries, or when you need to report on a certain point in time. For reusable assets, take a baseline at stability points. At most, take a baseline before delivering each change set in RM or DM, or after reviewing and approving a test case or test plan in QM.

You cannot currently roll back changes in RM. You can roll back in RTC SCM, and you can restore a baseline in QM. If necessary, in any of the applications, you can also branch a new stream from any baseline. For these reasons, you can consider baselines like backups, so take them as often as the amount of time you are willing to lose to rework. Baselines cannot be changed.

As with local baselines, take global baselines at key project milestones, when you need to capture the state of the product. For reusable components, take global baselines at key stability points, where other teams can choose to then pick up or “update” their own configurations with those baselines.

A global baseline automatically creates baselines of the local streams. You can take a global baseline, or you can manually add existing local baselines to a staged global baseline. Or, you could combine both approaches. Automation is appropriate if the global baseline creator is confident in the state of the local application streams. In the single-stream strategy, it’s quite possible that the same person manages both global and local configurations, so creating global configurations using baseline automation saves steps. Manual baseline staging is appropriate if you have more than one component stream, with local administrators who might baseline at slightly different times, so the global baseline creator cannot be sure of the exact state of the local streams.

Both local and global baselines can be taken on a timed basis (daily or weekly), and this approach allows comparisons over time or to see a previous state. These baselines can then be archived when no longer needed, such as when a milestone has been reached and baselined.

Links to work items: If you link versioned artifacts to RTC work items, at release boundaries you must also update the release that is associated with the global configuration. When your release ends, you take a global baseline and start on the next release. You then need to update the original RTC release association to point to the new global baseline. When you create the next release, associate it with your new iterations on the timeline and with the global configuration stream. Then the work items from the previous release still link to the original (baselined) versions of the artifacts, while new work items link to the current versions. If you take interim global baselines throughout your release, and if you set your configuration context in RM, QM, or DM to the global baseline, you don’t see the linked work items because the RTC release points only to the global configuration stream. Similarly, reporting on the interim global baseline does not include the work item links. If it is important to see those links in the global baseline context, you could partially address this by setting the release-to-global-configuration association for each iteration, and when that iteration is over, point it to the global baseline. These updates are done manually today.

Making baselines easy to find: You should use naming conventions to easily identify baselines. For global baselines, you can also define tags and custom attributes. GCM also offers a suffix when creating a baseline, which is applied to all children and local configurations at the leaf nodes of the hierarchy.

Read more about conventions for tagging, naming, and custom attributes in the Multistream variant strategy article.

Ensure that you archive baselines when you no longer need them. For example, after you have achieved a particular milestone, you might not need the interim baselines leading up to that milestone. Regular cleanup of baselines helps to manage performance as well as usability. In particular, archiving informs the Lifecycle Query Engine (LQE) that artifact versions unique to that baseline no longer need to be maintained in the data store.

Change management

In both RM and DM, you can choose to use change sets to isolate change from your main stream. Change sets work much the same in both applications, except that DM allows you to roll back a change set.

For more information

See the other articles in this series:

• Defining your component strategy
• Patterns for stream usage
• Multistream variant strategy strategy
• Multistream concurrent release development strategy

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

© Copyright IBM Corporation 2017