This guide describes concepts, components and functionalities of OSLC Connect for Jira in order to create Collaboration Links between Atlassian Jira and any OSLC-enabled application [1], [2]. Unless required, the target application will be referred generically through this guide as the OSLC Remote Application.
A Collaboration Link is a link between two elements that belong to different applications. Typically, when a Collaboration Link is created from one Application A to one Application B, a back link is created (automatically) from Application B to Application A, so both elements may have a way to navigate to each other. In this scenario, where a link can exist either because it was created on its own, or because it was created as the back link of the other link, it is often useful to distinguish their nature with a role name:
Once installed and properly configured [3], OSLC Connect for Jira allows to create outgoing links in both ends [4]:
Given the complexity of some products, some applications have implemented what is called Configuration Management. When enabled, this feature allows to define different versions of a given artifact and group them in components. Let's say a company wants to create a plane, the complexity would suggest us to split the design, and process in general, in components: the cabin, the wings, etc. Now, the design requirements for such plane to fly on America may be different from those in Europe; by having different versions of the same components (and the artifacts on them) engineers could achieve all this work easier: one version for America, one for Europe.
A configuration is, in this context, a version of a component: as many different component versions a team need to work with, as many configurations they need to create. All this is good up to one wonder what configuration on RM application should work with what configuration of QM application? In a collaborative environment, different applications care about different parts of the making process and, in a Configuration-Management-enabled environment, it is important to establish a relationship between configurations (from different applications) that work together, here is where the concept of Global Configuration comes in. A Global Configuration (GC) is a configuration where the artifacts are also configurations... but configurations from different applications (RM, QM, etc) that work together. In other words, the global configuration is the mean to define which local configurations work together.
Natively, Jira is a Change Management application. This means each Jira Issue can be seen as a (Change Management) Change Request artifact which is useful to track bugs, tasks or improvements.
Global Configurations have a limited participation in Change Management applications because it does not make sense to have different versions of a Change Request (there is no reason, for example,
to have a Task-123 version A for the American Plane and the same Task-123 version B for the Europe Plane; in such case, Task-123 is created for the American Plane and
Task-124 is created for the Europe Plane). Global Configurations, however, are still useful in this context to allow a Change Request to link with a specific version of a Test Case or Requirement
(Task-123 needs to work with American Plane requirements and test cases, whereas Task-124 needs to work with Europe Plane requirements and test cases). Out of the box,
OSLC Connect for Jira considers all Jira Issues as Change Requests and provides a way to determine what Global Configuration to use when linking with
remote versioned artifacts. This is done by making use of the Jira Versions and the fields Affects Version/s and Fix Version/s, whose value
can be mapped to a GC through an OSLC Link type. In other words, OSLC Connect for Jira allows to associate Jira Versions with Global Configurations [5], and
then decide what Version field to use (depending on the link type) to identify the right GC based on the values of the corresponding Version field.
All the above applies for Jira Change Request Issues but since OSLC Connect for Jira 4.0.0, Jira Issues can also be mapped to Quality Management
artifacts (Test Case, Test Plan, Test Execution Record, Test Result and Test Script) and even though Jira is a Change Management application by nature, Jira Issues can now be seen like any of the
previously listed QM artifacts. This comes with several implications when it comes to Global Configurations because Quality Management is meant to support versioned artifacts (contrary to Change Management).
OSLC Connect for Jira deals with this by making use of the Affects Version/s and Fix Version/s fields again but in a fundamentally different way.
This time, each Jira Version is treated as a local configuration which can be part of a Global Configuration. This means that the whole treatment of Global Configurations will depend on whether the working
Issue is mapped as a Change or Quality Management resource:
In other words, it is not enough, for Quality Management, to associate a Jira Version with a Global Configuration (in both applications: Jira and Global Configuration Management) but also to make the Jira
local configuration (Version) part of the Global Configuration in the Global Configuration Management application [6].
Once this is done, Jira Versions are treated as local configurations, specifically Stream configurations, if they are not yet released, or Baseline configurations if they are.
The QM Issues having these Versions assigned on the applicable field are considered part of these configurations [7]. The applicable field (Affects Version/s or Fix Version/s)
does not depend, this time, on the OSLC link type but on the QM resource type. To find out the standard field to use for both, Change Management and Quality Management, see
Standard Version Fields for Global Configurations for details.
Last but not least, OSLC Connect for Jira is Configuration-Management disabled by default. Each project requiring the capabilities described above must specifically turn on Configuration-Management and ensure Jira Version fields are part of the screen to Edit/View issues [5].
Following topics will include a Global Configurations Compatibility section to describe the differences over the general behavior when GC's are not involved.
Given Jira users are not necessarily the same as the OSLC Remote Application users, this guide is divided in two sections aimed to them: