How to Use Configuration Management with Atlassian Jira

Juggling product versions and releases can be arduous. If your team is tasked with developing a system, it will most often mean that you must manage co-existing releases as well as successive versions. You must deal with different versions of requirements, models, code, of test cases – each and every artifact along the lifecycle can exist in multiple instances. 

Keeping track of which artifacts belong to the lifecycle path for a specific release can turn out to be a challenge. 

Have you ever struggled with identifying that single, specific version of a piece of code that responds to this specific requirement related to a product release?

Are you missing easy access to versioned artifacts associated with your Jira releases?

Are you spending lots of extra hours preparing for reviews or approvals, trying to prove along the full lifecycle path that for each product release all artifacts are included in their correct version?

Would bi-directional traceability of assets hosted in all lifecycle tools involved help you master these challenges? 

If this sounds familiar, then you are in the right place. Keep on reading to learn how the combined use of configurations with Jira can help you address those challenges. 

Working with Jira Releases

A release in Jira identifies an event for which a specific instance of an artifact is delivered. When looking at a versioned asset, e.g. a requirement in IBM DOORS Next, you will be able to identify with certainty the correct workflow object related to this versioned asset, and vice versa.

A Jira release is a container encompassing work for a future release as well as content and work for a past release. With this mechanism, Jira users are able to maintain a comprehensive view of past, current, and future versioned artifacts associated with this release.  

As an example, let’s look at a defect in Jira: 

The details displayed indicate that this defect was present in release 1.0 (in the past) and it is planned to be fixed in release 1.1.0 planned for the future. This implies that the type of relationship that is associated with a link needs to be considered and should differentiate between versions. 

Let’s assume now that the “Solar Charging Module” is implemented to satisfy one specific requirement for release 1.0.

The correct implementation is proven by the “Solar Charging Test” which is linked to the “Solar Charging Module”. Conducting the test case shows an error, and the link between the failed test case and the original requirement is attributed with “affects requirement”. Resolving this error means implementation of a revised “Solar Charging Module 1.1.0” and the test is conducted without errors. The successful test case 1.1.0 is linked to the requirement with an “implements requirement” relationship.  

Like any other asset detail, the release identification is visible to any team member looking at a link to this asset. When a release identification is updated, all the links pointing to this asset are updated as well. For example, when a story needs to be moved to a different release (pull ahead or push out later), be sure to always reference the release’s current set of requirements. 

Working with OSLC Configurations

The OSLC standard defines a configuration as 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 instances in different configurations of that component. This provides an ability to uniquely identify a specific asset (artifact id) and the version of that asset (component configuration id). 

Individual “local” configurations for one component are helpful to manage a small set of assets. However, when connecting across teams, repositories, and domains, it is valuable to have configurations that span tools and weave together local configurations. In this case, a “global configuration” is useful to manage a configuration that spans multiple components. These configurations can be hierarchical, which provides the ability to include other global configurations into another global configuration. 

This concept is similar to the “systems of systems” approach, where subsystems of various types are aggregated to form a larger system. These global configurations can be streams (composed of collections of local streams or baselines) or baselines (composed only of baselined entities). 

Mapping between Jira Releases and OSLC Configurations

In a multi-version engineering project scenario, a specific release needs to be uniquely and unambiguously identified along the lifecycle and across asset domains. Since a Jira release is conceptually similar to an OSLC configuration, a simple mapping approach is the most obvious solution.

Mapping Jira Releases to a Configuration

The following example depicts a logical mapping of a Jira release to an OSLC configuration:

The assignment of a configuration to a Jira release is fully under the control of your configuration team.  

The mapping of a Jira release to an OSLC configuration is intended to be straightforward and deterministic.

It allows the identification of a specific version of assets (baseline or stream) that relates to a given release, and it provides simplicity and precision to users. Mapping should be as direct and intuitive as possible for a user to preview or navigate assets and understand the version relationship. 

Mapping – Summary and Conclusions

The flexibility and visibility achieved with aligning Jira releases and OSLC configurations provide for a solid basis for managing multi-variant engineering projects. While the capabilities are rich and offer huge potential, a consistent and well-considered configuration management process spanning the entire lifecycle, including workflows, reviews, and approvals is even more important. 

The foundation is laid by using OSLC Connect for Jira to integrate your engineering lifecycle tools and facilitate using OSLC configurations. Benefit from the advantages of a native, standard-based integration across tool silos and along the engineering lifecycle. Manage project work including tracking of requirements or test cases, and defect management, all the artifacts are accessible from Jira, no matter to which tool repository they belong. 

Leveraging the capabilities built into OSLC Connect for Jira will give you direct access to versioned artifacts associated with your Jira releases.

From within your Jira environment, you will see assets hosted in other lifecycle tools, linked to your Jira artifacts. Native Jira concepts are used to accomplish this transparency, without adding complexity to your daily work. Since this solution is based on linking data, you will always see the current version of linked assets. Duplication and synchronization become obsolete.