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.
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.
The standard way of Release Management in Jira is a long-lived “fixVersion“ field for any standard issue types. Thus, teams can define versions:
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.
There are some workarounds that teams are employing to overcome these limitations.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Following Atlassian visionary movement to the cloud we released v1 of 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.
We usually recommend:
All the links are available at Atlassian Marketplace.