One of the not-so-secret powers of Jira is its extensibility. Despite the power of its features, we cannot solve all use cases by configuration or by installing a marketplace App. That’s why having a modern and extensive Jira API (Application Programming Interface) makes the platform shine.
Our customers ask us to extend Jira when it reduces the burden on the shoulders of their teams. We all want our team to focus on high-value activities. This was also the driver to create the Traceability Verification App.
We developed the Traceability Verification app to solve a customer problem. They are a medical device company developing a sophisticated medical robot. Their device involves hardware and software and is an impressive example of engineering mastery. They keep product specifications in Jira Cloud: user requirements, medical device risks, functional specifications, and tests. The traceability links between the specification issues are using Jira’s built-in issue links.
For regulatory compliance, specifications are traced. Each high-level item, like a user requirement, traces down through layers of downstream specifications into test cases. Each test should have a successful execution.
The customer wanted to avoid two time-wasting tasks. The first was the case where they discover a traceability gap in the last stretch of the release. That could lead to last-minute delays. They also did not want to need to trace the linkage chains in Jira, to verify the traceability status of each issue.
Finding out the traceability status of each item is complex because:
- The sheer number of specification items involved. Each release involved a few thousand of these.
- There are more than five levels to the hierarchy. Also, the number of issues on the downward path could vary, based on which product components were involved.
- The traceability verification is dependent on the product version. An issue may have complete traceability for one version, and incomplete traceability for another.
The nice thing about verifying the traceability status of an issue is that it can be expressed in a formula. Thus we could delegate it to a machine. The machine will not only do it quicker, cheaper but also be more precise than any human.
Jira does not have a built-in feature for verifying traceability, and there is no marketplace app either. Having this automated was valuable enough to justify a custom development.
The Traceability Verification app
The traceability verification app has one goal: to show the traceability status of each of the issues involved.
The app adds two new fields to Jira issues:
- The field Verified Versions: This is the list of product versions for which the issue has verified traceability. Verified traceability means that there is a complete downward path from the issue to test runs, and all the test runs have a “passed” result.
- The field Verification status: This is an explanation for why the traceability is not complete. When the traceability is broken, it points to what needs fixing. This saves product managers and testers precious time.
These two fields not only provide information on the single issue level. They integrate with Jira’s search capability, so it’s easy to find issues that have a traceability verification problem.
How Does The App Work?
The traceability verification app delivers a simple user experience that is looking every bit like a native part of Jira. The user sees the two custom fields that are part of the full view of the issue.
The app hides under the hood a sophisticated calculation across the whole traceability chain. A periodic process interacts with the Jira API and recalculates the traceability fields for all issues, across all versions. The calculation is driven by the complex set of traceability rules. The Jira administrator has control over how often this process runs.
The processing steps are:
- Retrieve all issues involved in the traceability matrices (this is done via the Jira API)
- Iterate over all versions of interest:
a. Climbing upward, from the test runs all the way to the top of the traceability:
b. Run a recursive process that calculates the two custom fields for each issue. Consider in the calculation the traceability status of all the descendants, as well as the local conditions of the current issue.
3. Once the traceability is calculated for all issues, push the update to Jira (this, again, is done via the Jira API).
Technology and implementation choices for using the Jira API
The app would run on Jira Cloud, providing us with two development platforms: Atlassian Connect and Atlassian Forge.
Atlassian Connect has been around for a few years. It is a more mature technology so it’s more powerful and stable. It is the platform used by most Atlassian Marketplace apps. The drawback of using Connect is the infrastructure. A Connect app requires a computation infrastructure external to Atlassian.
Atlassian Forge is the newer framework and is still limited and rough. Forge is a “FaaS” (Function As A Service) framework and thus is hosted on Atlassians’ infrastructure. If using Forge, the customer will need to maintain none or a lighter external infrastructure to host the extension (compared to if using Connect). Forge is free to run at least until 2023.
RadBee has experience developing on both Connect and Forge. For this project, we used Forge because we wanted to maintain a smaller infrastructure. All the user interfacing elements would run on Forge, on the Atlassian infrastructure.
In the Traceability Verification app, the single element that could not run on Forge was the calculation of the traceability status. At the time of implementation, Forge limits the processing cycle of a single calculation to 25 seconds. This is too low given the number of issues we wanted to benchmark against. Hence we opted to run the processing outside the Atlassian infrastructure.
Our customer already had infrastructure on Google Cloud Platform (GCP), so we delivered the Traceability Verification calculation on a Google Cloud Run instance. We leverage the CPU allocation policies available on this type of instance to achieve an excellent cost profile. In fact, we expect that the usage of the GCP infrastructure will mostly fall under the free tier.
The End Result
With this app working in the background, the team can focus on their product development. Product owners and testers see immediately if an issue has a wrong traceability verification status. Even better, they know where the traceability breaks and why, so they know exactly what to fix. Now the team spends more of their time writing better tests and fixing product bugs.
The App runs on the Atlassian infrastructure, so the app does not store data externally. This helped secure the support of the cyber security team. For brief bursts, there is a serverless function on GCP which calculates the traceability status and evaporates.
And the costs? Atlassian is not charging extra for running a forge app, and the serverless execution on GCP is less than 10$/month. The ongoing costs of that infrastructure are negligible.
This Is The Power Of Jira’s API and Development Platform
Not every wish or feature gap warrants a custom Jira extension. After all, developing an extension can be costly. But, when an app can save tons of time of your most constrained resources, that’s a classic example of an app worth developing.
As detailed in our Quick Start Guide to QMS article, you have three paths to extend Jira. First, you use configuration options that are accessible to any administrator through the admin area in Jira. If you need more, check out the Atlassian Marketplace. Chances are that you’ll find an App that is a good fit. As a last resort, you have the option to extend Jira with a tailor-built App. With a tailor-built App, the sky is the limit.
Do you think you might need a custom App? Contact us to find out if our team can help you unleash the power of the Jiras API.
