Introduction to Configurations and Global Configurations
If you read Enabling Lifecycle Collaboration with OSLC, you saw that we did not speak about Configurations. So what are Configurations? And what are these Global Configurations you keep reading about?
What are Configurations? Asset Versioning!
The OSLC Standard provides a method to account for Configurations of sets of assets.
A Configuration is a collection of assets of a specific version that are contained in a component. A component can have many different Configurations. These Configurations can either be static (a baseline) or dynamic (a stream). Additionally, a given asset can be contained only in a single component, and it exists as different versions in different Configurations of that component. This provides an ability to uniquely identify a specific asset (artifact id) and then the version of that asset (component Configuration id).
A Configuration of a component is considered a “local Configuration” as it manages a single container's Configuration in a single repository. Components exist in any repository that controls assets. We see these components in IBM DOORS Next (DNG), Engineering Test Management (ETM), Rational Model Manager (RMM), Change and Configuration Management (CCM), and other OSLC Configuration enabled tools. Each of these tools enables users to create streams and baselines of these components.
What about Global Configurations? Cross-Tool Asset Versioning!
Individual Configurations are valuable to manage a small set of assets.
However, when connecting across teams, repositories, and domains, it is helpful to have Configurations that span tools and weave together local Configurations. In this case, a “Global Configuration” is useful to enable the naming of a Configuration that spans multiple components.
These Configurations can be hierarchical, which provides the ability to include other Global Configurations into another Global Configuration. Think of this as aggregating subsystems together into a larger system. These Global Configurations can be streams (composed of collections of local streams or baselines) or baselines (composed only of baselined entities).
The result of this is that we now have a Configuration that sets both scope and versions of artifacts that can be named (and managed). Conceptually these Configurations are similar to Jira Releases but rather more precise in the definition.
Many tools provide local Configurations. But some of them, like Siemens Polarion and Siemens TeamCenter, do not support Global Configurations.
SodiusWillert’s OSLC Connect solutions, such as OSLC Connect for Jira and OSLC Connect for Confluence, support Global Configurations.
For more information on OSLC Connect for Jira’s support for Global Configurations, you can read Using Configurations With Jira.
In the tool landscape, Global Configurations are provided by IBM Engineering Lifecycle Management’s (ELM) Global Configuration Management (GCM) application.