Releases are at the core of every project; they help teams organize the delivery of their work and act as a historic reference for future needs.
Jira releases are good for managing your releases at a project level. However, difficulties arise when you try to use Jira for release management across multiple projects.
Release hierarchy in Jira
In Jira, you can create many projects, and for each of these projects you can create issues. If you want to track your issues better, Jira offers many options to tag the issues; that includes fix versions (aka releases), components, labels, epics, sprints, custom fields and many more.
- Releases and components are project-specific and cannot be linked to the issues from different projects.
- Labels and epics in Jira are global and can be used to tag issues from any project.
- Sprints are dependent on the board; if you run a board with issues from multiple projects then you can include any of them in the sprint.
So where's the problem? This hierarchy is just way too restrictive for cross-functional teams.
When the operation gets bigger teams often decide to split into many smaller projects in Jira. These projects can represent different teams, clients or parts of the operation.
This approach is especially helpful because each team can manage their own tasks, can have different workflows, reports, etc. But when it comes to releases they still need to release only one version that delivers tasks from several of these projects.
The solution for having the same Jira release in multiple projects is to create a fix version (aka release) with the same name in all the needed projects. This will enable you to link issues to the needed version. Now we can also JQL by version name to get a list of all issues delivered in this cross-project release.
But here's the thing, these versions aren't connected to one another. If we change anything, from name, to description, release dates or status, we'll need to do it for all for all of the projects manually. And this becomes hard to manage after a while.
Cross-project or portfolio releases aren't part of the core functionality of Jira, but they can be added by using an external app like Swanly.
How to create cross-project releases in Jira using Swanly
In Swanly, you can create a release with multiple projects assigned.
There are 2 ways to create a cross-project release:
- by creating a new release from scratch,
- by adding additional projects to the existing release.
Jira versions are then automatically created in each of the selected project and any changes made to any of these versions are then automatically synchronised. Magic! 🎩🐇
You can now assign issues to these versions as usual and instead of updating Jira versions, you can focus on delivering your project.
Swanly provides much more than just the Jira cross-project releases sync functionality. It showcases your releases in a portfolio release timeline or a list view that you can filter through, and provides advanced release reports on-the-go with:
- aggregated story points and time tracking
- a list of issues linked to the version and another of issues that affect the version
- release history
- release burndown chart
- release phases and stages
So you'll find everything you need to know about your releases in one place.
Yes, free; you can install the app for free if you're 10 users or less, or you can try the demo and see.