Configuration management
Complexity is one of the biggest challenges facing software and systems engineering teams today. Software applications are built by integrating many software components, each with associated artifacts such as requirements, designs, source code, and test plans. Teams often work on several versions of an application at the same time. Changes to specific artifacts must be incorporated in a controlled manner to prevent errors and maximize reuse.
Similarly, system engineers design products that are built from hundreds or even thousands of individual components, which can range from physical objects to software. Related products are often produced from a common base or architecture and grouped into a product line.
Product lines can contain dozens of closely related products, also called product variants. A variant is identified by a specific set of characteristics that distinguish it from other artifacts or products in the product line. And behind each product variant is a specific set of artifacts, such as the requirements, designs, source code, and test plans that were used to formulate it.
Configuration management capabilities in IBM® Engineering Lifecycle Management help teams manage this complexity.
- For pilot environments, generate an activation key using Enabling
configurations in ELM 7.0.3
applications.Note: The configuration management capabilities of the RM, QM, and Global Configuration Management applications are added services for IBM Engineering Lifecycle Management as SaaS and IBM Engineering Lifecycle Management SaaS customer environments and must be enabled only by the SaaS provider. The source-control management (SCM) feature in Engineering Workflow Management is included in Cloud offerings at no additional cost.
- For production environments, discuss your plans with your IBM Client representative or contact IBM Support.
See additional learning resources at the end of this topic.
Configuration management concepts
Teams use Engineering Lifecycle Management tools to develop wide-ranging applications, such as banking software or medical devices. As part of the development process or engineering design, teams create a variety of artifacts, ranging from stakeholder and system requirements, to source code, to test plans and test cases.
A component represents physical or logical pieces of the software or system your team is working on. For example, you might create a component for a physical piece, such as a heart monitor, or a logical piece, such as the server. Each of these components can have several configurations.
In the Engineering Lifecycle Management tools, you use configurations to group a set of versioned artifacts in a project area. Configurations commonly identify one version of each artifact in the set. For example, a team might group all the requirements for a component into a configuration, making it easier to identify and work with all the requirements associated with that component.
- Streams are modifiable configurations of artifacts from one or more components. Team members deliver their changes to a stream when they want to make their changes visible to other team members.
- Baselines are frozen configurations of artifacts (cannot be modified) from one or
more components. Baselines are useful for enabling a team to work with a known configuration, or as
an initial state for some new stream of work.
IBM Engineering Workflow Management makes a slightly different distinction for source control management (SCM). Baselines of components are the same, but snapshots represent a frozen state of a stream that contains component baselines.
Artifacts in a stream can be modified, and the stream always presents the artifact version that is currently selected by that stream (other streams or baselines can select other artifact versions). By maintaining the artifacts for a project in a stream, teams can share their work and ensure they are working with the artifact version that they need.
When the work on a set of artifacts in a stream is complete or has reached some milestone, you can create a baseline of that stream to capture the specific artifact versions selected by the stream at that time. The artifact versions in the baseline cannot be modified, nor can the set itself. In the future, the team can use the baseline to create a new stream for its work.
Configurations enable parallel development
New features in this release enable parallel development.
- For software applications, the current stream might be used for the next version of the
application or product while a new branched stream is used for the first maintenance fix pack.
Changes in the maintenance stream can be delivered to the current stream, so the next release
includes all changes from the maintenance fix pack. For many years systems and software development
teams have used configuration management in this way to develop parallel releases.
To branch a stream, first create a baseline of it; then, create a new stream from that baseline
- In a product line context, the initial stream might hold all artifacts associated with one
product while the new stream holds the artifacts and versions associated with a new product variant
under development. Several variants can exist at the same time. This is how teams manage versions
and variants.
Assemble configurations to represent a specific version of a component or product
- Provides your team with a holistic view of the artifacts (requirements, test artifacts, source code) for a specific version of a component or product. The view enables your team to develop multiple versions of an application or product in parallel. As you work within and across Engineering Lifecycle Management tools, you see only the artifacts relevant to the version of the component you are working on.
- Creates a hierarchical component structure that reflects the system under development and
enables subsystems to be updated independently. By grouping multiple configurations from different
tools, you can represent the artifacts associated with a complex and aggregated subsystem, such as
an engine, or complex component-oriented applications.
In Engineering Lifecycle Management tools, you can create multiple components to represent pieces of your product or system. You can then create configurations of these components and contribute them to globally-managed configurations by using the Global Configuration Management application. Globally-managed configurations are called global configurations to distinguish them from locally-managed configurations, or local configurations, created in components in Engineering Lifecycle Management tools. Global configurations can contain global configurations, local configurations from Engineering Lifecycle Management projects, or both. Local configurations contain artifacts from the Engineering Lifecycle Management tool where they were created.
This release and the OASIS Open Services for Lifecycle Collaboration (OSLC) specification use the term “global configurations” to distinguish them from the local configurations that contain only artifacts. Any tool can contribute configurations to a global configuration if it supports the OSLC configuration management specification.
An example of configurations in practice
Suppose your team is building Version 2.0 of a medical device application or product. Your team's
requirement configurations are in IBM Engineering Requirements Management DOORS® Next; the
source code configurations are in Engineering Workflow Management; the
test configurations are in IBM Engineering Test Management. Each
Engineering Lifecycle Management
tool contributes a configuration (a stream with the correct artifacts) to Version 2.0. These local
configurations together form a global configuration named Medical Device Version 2.0 (
), which a configuration lead has assembled using the Global Configuration Management application.
The following concepts are specific to the Global Configuration Management application.
As your team works on Version 2.0, team members realize that they need another variant to address unique regulatory requirements for a specific market, such as Europe (and potentially other markets as well). The team must also develop new code, and create test cases and plans.
The team creates a baseline of the Version 2.0 stream that contains the configurations and artifacts they will need, and then creates a stream from it for their new work, called Version 2.0.1 EU.
The team will work on both products in parallel.
The parallel stream is typically created by a team member with administrative privileges who is designated as a configuration lead. In this example, assume that you have been assigned those permissions.
- Before you can branch Version 2.0 to create the stream, you must create a baseline
in the relevant Engineering Lifecycle Management tool for each configuration that contributes to the
Version 2.0 stream. Each baseline captures the artifact versions that the Version 2.0 stream is
using. This example has the following baseline names:
- Version 2.0 (requirements)
- Version 2.0 (source code)
- Version 2.0 (tests)
- Branch the Version 2.0 stream to create a stream across all three Engineering Lifecycle Management tools
for the team’s new variant work:
- In the global configuration application, copy the Version 2.0 stream and name it, such as Version 2.0 Milestone.
- In the Version 2.0 Milestone stream, replace the contributing streams with the baselines that you created in the Engineering Lifecycle Management tools.
- Convert the Version 2.0 Milestone stream into a baseline. It is important to make it a baseline so you know which set of configurations to start with. The baseline freezes the milestone release but keeps the Version 2.0 stream open for more work.
- Create a stream from the Version 2.0 Milestone baseline and name it Version 2.0.1 EU. This action branches the stream so that you can start working on the EU variant.
- In each Engineering Lifecycle Management tool, create streams from your baselines from Step 1.
Remember that you created the baselines to freeze artifact versions, so you cannot modify them.
You'll want to modify some artifacts in these sets, so use the relevant Engineering Lifecycle Management tool to create a stream from each baseline.
- In the Version 2.0.1 EU stream, replace the baseline configurations with the new streams from
the Engineering Lifecycle Management tools.
Now the team can make the changes for Version 2.0.1. They update the necessary requirements, source code, and test cases, and then deliver the changes to the Version 2.0.1 stream.
Changes made in one stream are isolated and do not show up in the other stream. For example, if you change a requirement artifact in one of the streams contained in Version 2.0.1, the change is isolated from the other stream until you deliver your change.
As you use links to navigate to different products from a global configuration, you remain in the same context. This ensures that your work is completed in the correct stream, isolated from other streams and baselines.
At a significant milestone, such as the completion of a sprint, you can create a corresponding baseline from a global configuration to freeze the artifact versions. Use the baseline to start a new development stream or to base other work on, such as a fix pack. You create a new stream from that baseline.
By using the new capabilities in this release, your teams can reduce the complexity of parallel development, control and isolate delivery of changes, and understand how artifacts are grouped and used across application and product versions.