CLM configuration management: Patterns for stream usage
This article is part of a series that provides guidance for planning configuration management for the IoT CE solution.
Introduction
This article introduces several patterns of stream usage, or stream strategies, which are described in more detail in additional linked articles. You should already be familiar with the configuration management capabilities, and have decided to investigate further. For the introduction to this series, see Adoption guidance and practices.
As part of planning your adoption of configuration management you need to determine your stream strategy. Ask yourself:
- What working streams do you need for the local and global components you have identified (see Defining your component strategy)?
- When should we create new streams, and from what baselines, for both global and local configurations?
- When should we capture local and global baselines, and how will use them?
- How should we use change sets (if supported)?
- How should we deliver across streams (if appropriate)?
Remember, streams are configurations where you can change the artifacts, as opposed to baselines (or snapshots as they are called in Rational Team Concert source code configuration management), which are frozen and capture the state of the artifacts at a particular time.
Your stream strategy must address the global configuration level as well as the local configuration level. Note that creating a new global stream doesn’t necessarily imply creating new streams for all of its contributions; previous work can be reused.
In general, keep your stream strategy as simple as possible, with the fewest streams that still meet your needs. Use the patterns in this article, along with the detailed related articles, to determine which strategy best suits the needs of your organization. Your strategies might evolve over time.
Although you should aim for a consistent strategy across projects within an organization, some projects might have different needs that require a different strategy. Use this guidance to select the appropriate strategy for each project, although you might want to consider the benefits of having a consistent strategy across projects.
This series of articles is written for the general case including configurations for different artifact types, but applies also to cases involving only a single artifact type. The articles also assume that the stream strategy is consistent across domains, and across the global and local components and configurations for that project area, although that is not required. For example, you might decide to retain your current source code stream strategies, and simply contribute the streams and baselines to the appropriate global configurations. The other articles in this series give more detail and might address some alternatives.
Single stream pattern
The simplest approach is to have a single stream, where all artifact changes and resulting new versions are progressed along a single path. At any time, there is only one “latest version” of any artifact. At a release or milestone, you create a baseline and continue working in the same single stream.
This approach is commonly used when you are building a single product, such as a website. Everyone is working on changes for the next release of the product to publish. At any point, all team members use the same version of the product, so there is no maintenance of old releases, just changes for the next release.
If you are using only a single component with a single stream, you don’t need a global configuration. Depending on your needs, you might not even need to enable configurations at all; each application provides basic support for baselines of a single stream without full configuration management:
- You can take baselines for a non-enabled requirements management (RM) component. However, you cannot create change sets in a non-enabled project. Change sets for requirements enable you to better control change and to group related changes.
- You can enable a quality management (QM) component for “baselines only”.
- Design Management (DM) and Change and Configuration Management (CCM, used for source code) do not require any enablement to support baselines and change sets.
If you have or expect to add multiple components within a domain or across multiple domains, each will have its own streams, and you will need configuration management and a global stream to group them.
You can use a single stream even if a downstream team, such as Test, requires a stable baseline to do their work (trace tests back to a stable set of requirements), while the upstream teams continue to make updates. In this case, the testers use a global configuration that includes a baseline of the requirements, while the Requirements team makes changes to the current versions.
For more information, see the Single stream strategy article.
Simple promotion pattern
Even if everyone is working toward the same target at the same time, you might choose to have multiple streams to support a promotion model, where new features or changes can be worked on, which then require approval before inclusion in the current release. For example, you might want a separate Development stream where all change activity occurs, and then move the changes into a Release stream only when they are committed for the release.
As in the simple stream pattern, you baseline both streams at appropriate milestones, and continue to use those streams for the next release.
There are several reasons why you might choose to have separate development and release streams:
- Support agility to make late changes on what is included in a release.
- Provide more governance over delivery to the release stream, including the potential to hold reviews in the development stream before delivering to the release.
- Provide a stable release stream for downstream consumers to use, insulating them from incomplete development work. (You might also address this need in a single stream strategy by providing baselines to downstream teams.)
- Enable reporting on “work in progress”. (You can’t report on a change set, but you could report on the development stream.)
- Avoid delivery conflicts that could happen from large and long-lived change sets when approval takes place only at the end of the cycle.
- Enable additional validation for import or ReqIF scenarios within the development stream instead of within a single change set.
Simple maintenance pattern
Like the simple promotion pattern, the simple maintenance pattern has two active streams. However, it also has a set of inactive streams. The first active stream is the Release stream, which will be used as the source of record for all official releases (through baselines at release time), and where the development team makes changes working toward the next release. The second active stream is the Maintenance stream, which will branch from the official release baseline and contains changes from maintaining that official release. This pattern relies on several assumptions:
- Only one release is in maintenance at a time.
- Each subsequent product or system release from the release stream completely replaces the previous one.
- Fixes made in the maintenance release must be delivered to the new release stream (if they apply). Deliveries flow only from the maintenance stream to the release stream. This isolation of maintenance work reduces the risk of impacting items that are refactored in the release stream.
- Before the final release from the release stream is produced, ensure all relevant maintenance changes are delivered back to the release stream.
- When a new release is ready in the release stream, the current maintenance stream becomes “inactive” and a new maintenance stream is created for the latest release.
- You can archive inactive streams when you no longer need them.
Parallel development of multiple sequential releases
In many cases, teams work on more than one release at a time and also maintain multiple releases. For example, you might have sequential product releases (R1, R2, R3, and so on) where you start work on the next release before the current release ends, and where you must provide maintenance for all those releases. So, you must use parallel streams to keep the content separate for these concurrent temporal releases. (Concurrent releases to address variance, such as regional or supplier differences, are addressed later in this article).
Each release might itself have more than one stream to support promotion or maintenance, or for other reasons. Your stream strategy must address the additional streams and complexity.
Parallel development of multiple variant releases
The other primary driver for multiple streams is variants. For example, if you have sequential product releases (R1, R2, R3 and so on), but the content varies by region (such as R1NA, R1EU, R1AP), then you need a stream for each variant that is part of the overall release. A more complex pattern uses (1) multiple streams to manage variants and (2) multiple streams branching from each variant stream to manage parallel work on multiple releases of each variant. Other streaming patterns are also possible but are not discussed in this series.
Another article in this series discusses three candidate approaches for creating a global configuration that is used by a team building a software solution out of their components:
- Fortuitous reuse: The solution teams begin by reusing the “closest match” global configuration they can find and tailoring this to meet their needs.
- Application engineering pattern: The solution teams select components from a common platform as a starting point, and add additional content that is needed to define their solution.
- Domain engineering pattern: The available lifecycle artifacts are intended to provide a superset of what is needed to compose a new product or product variant. In this case, the solution teams filter the available content down to the specific artifacts that they need.
For more information, see Multistream variant strategy.
Summary
Choosing a stream usage pattern is a unique exercise for each organization. It is possible to move from simpler to more complex patterns, so choose the simplest pattern that satisfies your needs for the immediate future. The main factor in determining a stream pattern is “How many teams need to work in parallel on different versions of the same artifacts?”
As part of defining your stream strategy, ensure that you also define:
- When to create new streams, and from what source or baseline, at both the global and local levels
- When to capture global and local baselines, and how those baselines are used
- How to use change sets (if supported)
- How to deliver across streams (if appropriate)
Also consider metadata to identify components and configurations, including tags and custom attributes; currently these are supported for global and source code components and configurations.
See the other articles in this series for more details on those aspects.
For more information
See the other articles in this series:
- Adoption guidance and practices
- Defining your component strategy
- Single stream strategy
- Multistream variant 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 authors
Doc Brown is the Chief Architect for Continuous Engineering in IBM’s Watson IoT Lab Services. Doc has been in the systems development business since 1980, and supporting clients using Rational/IBM products since 1997. In addition to supporting IBM’s most strategic clients, and the IBM teams that service them, Doc has advanced the state of the practice of systems development through his extensive process work including the Rational Unified Process – Systems Engineering (RUPSE), Model Driven Systems Development (MDSD), and the IBM Systems Engineering process. He can be contacted at dave.brown@us.ibm.com.
Kathryn Fryer is a Solution Architect who works with customers, sales, and development to develop usage models, aid adoption, and improve product offerings. She can be contacted at fryerk@ca.ibm.com.
Ian Compton has worked in software and system testing for 17 years, starting testing DOORS V4 for QSS in 1999, and moving on via Telelogic to system testing the IBM CLM, and then SSE and CE solutions. He has recently started a new role as a solution architect for the pre-sales team at Persistent Systems Limited. He can be contacted at ian_compton@persistent.com.
© Copyright IBM Corporation 2017