Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Release Management is the next big thing for Atlassian Jira


Powering - more than 80% of Fortune 500 companies list Atlassian Jira (Jira) has become a golden standard for software teams globally to plan, develop, test and release software products.

From its earliest days Jira focused on the development phase to introduce Agile and Lean principles and practices into their solutions. This gave development teams limitless options to manage their development process the Agile way. With “Portfolio“ acquisition and conversion into Jira Roadmaps, the vendor closed the gap of planning phase with an out of the box solution.

The two remaining phases - testing and releasing - have become the target for loads of individual vendors worldwide to deliver possible solutions via Atlassian Marketplace.

Test Management seems to have found its way with Apps like Zephyr, Xray, TM4J and others. Therefore, software teams have pretty good alternatives to choose from.

Release Management, however, in most of cases, was done outside of Jira with standalone CI/CD tools. This obviously created some gaps and presented a need for middleware to connect the dots for seamless processes. In this article we would like to present Release Management for Jira as a challenger to find it’s niche and close the gap within the release phase of software products with Jira.

Jira Releases

The standard way of Release Management in Jira is a long-lived “fixVersion“ field for any standard issue types. Thus, teams can define versions:

  • either by the old-way, via Project Administration / Version Management
  • or the new-way, via Jira Releases section of the board for Classic and Next Gen projects.

So, by specifying “fixVersion“ for Jira issues we actually assign them to one of the versions. Versions have Start Date and Release Date as well as 2 predefined statuses - Released / Unreleased.


Looks like it’s enough? Apparently, not.

  • in most of cases teams want to extend versions workflow to better track progress and/or rollout.
  • most current solutions are multi-component. This means in Jira they are handled by different teams in different projects. So, the actual release is a cross-project exercise. This is a some what limiting, since Jira versions are tied to a single project.

Some workarounds

There are some workarounds that teams are employing to overcome these limitations.

“Change Management“ Projects

Teams often create a custom project for Change Management. Versions are tracked in such projects as standalone issue type with custom workflow being linked to multiple project versions / issues. This requires a serious amount of manual maintenance to keep the integrity of the entire solution.



One issue type that works across projects and has good internal tooling, is Epic. So, some of the teams that are practicing CD, deliver through Epics that are composed of multiple user stories and technical tasks from different projects. Others go a bit too far - substitute Agile notion of “Epic“ and use this issue type as “Release” notion. The tool has no restriction against doing so, though this seems an anti-pattern just for the sake of having cross-project release functionality.

Release Management for Jira

To overcome the above challenges we created our Release Management App.

The idea seems straightforward: - We enable teams to bring versions from multiple projects onto a single Release board and define custom versions workflow, matching it to Releases/Unreleased statuses.


This creates a foundation for building some good features on top.

Key features

As mentioned above, at the core of the solution are Kanban-style release boards with versions from multiple projects. Teams can define custom workflows for versions represented as columns on the board, share boards with colleagues and/or restrict access to them for certain groups. Versions are moved through workflow using drag and drop functionality. Any changes on the board are automatically replicated in Jira Releases and vice versa. So, the solution we have  developed is not a replacement for Jira Releases, it’s designed for cross-project Releases.

Release packages

To manage multiple (maybe re-current) releases, we have created a new entity called Release (“Package” in Cloud Version). Release packages have Start Data, Release Date and their own board with a custom workflow. Swimlane view allows to track versions progress within packages on the same board.


The most common-common- use cases are

  • recurrent multi-component releases in which components are tracked within their  own projects
  • rollout activities when each and every client/environment get a version prefix


Timeline view is intended to create a  Delivery Roadmap ( not to be confused with Product Roadmap). Thus, existing packages/versions can be put on the timeline with progress tracking or new versions could be created automatically in specified Jira projects as an outcome of planning exercise.


Release notes

All teams like producing and introducing new features for their products, A/B test them insegments, and rollout. But all of them absolutely hate writing release notes for it.

We have tried to make their lives easier and save them a bit of time through the use of automatic release notes. Teams can create predefined templates using a rich library of release variables and custom JQL functions to extract the scope of each version and other details.


Release notes may be generated automatically as a post-function, after moving a version to a specific column at anytime, on demand.

The output can be downloaded as HTML. At the moment we are considering ways to automatically upload it into Confluence to stay within the  Atlassian eco-system.


Teams are using multiple environments throughout development and testing. Modern solutions are also deployed to geo-distributed infrastructure. This leads us to the fact that releases and environments are linked to each other in ‘many-to-many’ relationships.


We allow teams to create all their environments (in the future it will also be possible to  link to environments in Deployment tools) and mark them by categories. We also allow the user to specify where the current release version is deployed so that teams have full tractability of what is deployed and where.



We truly believe that any solution needs to be extensible in order to give teams ultimate flexibility to tweek it to their needs.

Rest Api

We provide public Rest Api alongside our Apps. We actually “eat our own god food“ by using the same Api via our client App. So, almost all of the features available via our App are also available via Api.


The use case of the Api usage is automation with third party tools (like CI/CD) to trigger actions in Release Management following certain actions in 3rd party tools.

Web Hooks

As we write this article, our own team is finalizing the new release of the App to allow Web Hooks from Release Management App. We will provide some predefined templates for requested integrations, in particular Slack, Jenkins and Bamboo.

Reports and Gadget

Nowadays “Data” is king and queen. Therefore, we are building a rich library of reports available from the App. Most of the reports are also available as Gadgets to be put on Jira Dashboards and/or integrated in Confluence pages.


One of the key disciplines of Release Management (especially in Enterprise) is stakeholders’ expectations management. We are happy to advise our clients on different ways of providing ultimate visibility of the  release management process and its deliverable, using the Release Management App.

Is it available for DataCenter?

Yes, we have completed the initial set of requirements and have conducted some latest tests to get our App fully certified for DataCenter.

We always keep parity between Server and DataCenter editions in terms of key features.

What about Cloud?

Following Atlassian visionary movement to the cloud we released our Cloud App. Now we are in the process of migrating key features to enrich our cloud offering. We are also happy to support our customers with migration to cloud, if applicable.

How to get started?

Both Apps - Release Management for Jira and Release Management for Jira Cloud - are available on  Atlassian Marketplace.

We usually recommend:

  • watch a quick video
  • Try it Free
  • start from our quick guide (in the app and also in the documentation)
  • explore more in our documentation
  • frequently read “what’s new?” with new versions upgrade
  • schedule a session with our support team to do a product demo and/or get advice on your particular use case
  • or send us questions via the service desk portal

All the links are available at Atlassian Marketplace.

Stay tuned!



Log in or Sign up to comment
eva_konrad April 20, 2020

Dear @Yuri Kudin ,

Thank you your article.

I have one more question: can I use the release versions as global settings or paralel in some progects. Or this is property for only one project?

Thanks in advance,

Like Yuri Kudin likes this
Yuri Kudin April 21, 2020

Hello @eva_konrad ,

Thank you for your interest in the article.

Out of the box, versions belong to one project and can't be used in the global context. 

In our add-on we tried to overcome this limitation by introduction of Releases or Packages (in cloud version). Release aggregates multiple versions from several projects in order to take a global view on cross-project, multi-version deliverable.

Hope I answered your question.


Like eva_konrad likes this
Wouter Bruinings
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 20, 2022

Hi Yuri,

I have enjoyed reading your articles and I can imagine multiple enterprise companies must be coping with this issue. 

Thanks for the informative posts on release management and introduction to the plugin.


Michael -Get Report- May 4, 2023

Yuri, this is such an insightful article! thank you for this!

AUG Leaders

Atlassian Community Events