Release Anything (or Taxonomy of Releases)

Owned by Yuri
Last updated: Apr 11, 2024
11 min read

For a long time Versions (also called Releases in Jira) associated with Versions look up on Project level. To assign Jira issues to Versions (Releases) two standard fields are used, namely “Fix version” and “Affects version”. The later is used rarely so it’s all about Fix version” mostly.

This is smth we support natively in the App - fix versions and issues being assigned to it. Sametime, a number of companies are using other ways to define releases - a container of issues. In particular the following approaches are used:

  • Single- or Multi-select Custom fields with predefined values

  • Labels

  • Epic as Release (mainly because Epic could be shared among multiple company-managed projects)

  • Sprints (when teams are delivering every sprint)

  • etc.

Also on a number of occasions work is split across multiple projects and release scopes presume issues completed in a number of Jira projects. Theoretically clients what to track it as One Release, but Fix Versions are project bound and could only be created in scope of release

Flexible Release Taxonomy

With Release Management App we aim to answer the above challenges by giving clients flexibility to define scope of their Releases and structure it according to business needs.

To start with, we support

  • Single Project Versions - classical Fix Versions (Releases) from Jira outlines above. Same time we greatly extend it with our own capabilities.

  • Cross Project Versions - an aggregate of Fix Versions from multiple projects that a synchronized automatically with Name, Description, Start Date, Release Date. Change an of those will trigger automatic change in the rest. Cross Project Version is also an additional entity with Release Management App alongside encompassing Fix Versions that could be managed separately or in coordination with fix versions. Read more below.

To go further, we support alternative ways to define scope of releases (not via Fix Versions), namely

  • Epics

  • Sprints

  • JQL Versions

We call them Virtual Versions. Read more below.

And last but not least, we allow creating Meta Releases (we call it Packages), that’s an aggregate of Single- or Cross- Project versions, Virtual Versions to define complex Releases.

Single Project Versions (Fix Versions)

Single Project Versions | Fix versions | Releases are Jira standard entities that come out of the box with your Jira instance. If you do not have it available you might need to toggle that feature, in particular

Scroll to your Project Settings

Select Features and toggle Releases

As a result, under Development section you will get Releases

Do not confuse it with Release Management App. You need to scroll further to find it

Creating Fix Version

In Jira you need to click on Create version to get a new one

You would need to specify

  • Name

  • Start/Release Dates

  • Description

The above are the main properties used. In latest versions of Jira Atlassian started to add some additional properties like Driver for e.g. Probably more will come in the future.

In Release Management App you either need to put mouse in any of the columns to add versions inline or click on Add Items to open up a panel

Editing Fix Version

To edit Fix version on Jira you either can select Edit menu item from the list of releases

or Click on the version to get into version details screen to edit inline

In Release Management App you just click on any Version to edit.

In Release Management App we inherit all Jira capabilities to extend versions with

Cross Project Versions

Cross Project Versions is an aggregate of Fix Versions in multiple projects selected. When creating Cross Project Version the App will create Fix Version with the same Names, Start/Release Date and Description in select projects as well as designated entity for Cross Project Version.

Creating Cross Project Versions

The difference is easy - your just select multiple projects.

So, either click inline or select Add Items

As a result

Editing Cross Project Versions

All project instances of Cross Project Version + aggregate are fully in sync. Editing Name | Description | Start | Release Dates will trigger the change in all the other instances and it does not matter whether the change is coming from the App, Jira, API or Automation.

All the other properties, namely:

  • Custom properties

  • Milestones

  • Components

  • Dependencies

  • Environments

Are different for all the individual instances and aggregate.

When you click on Cross-project version you will see will see the following:

  • Issues statistics will be aggregated for all the individual version

  • You will see list of projects as opposed to single one

List of Projects is editable.

  • Thus you can add more projects that will result in creating another single project version with same Name | Description | Start | Release Dates

  • You can delete the project from the list that will result in Fix projects excluded (not deleted) from cross-project version meaning the Name | Description | Start | Release Dates won't be in sync any more

  • but it should be at least one project in a list

Issue view will have an aggregate of all issues from all Fix versions included.

You can also add issues in specific Fix Version.

When you click on Add existing the App will automatically recognize the project and assign Fix version from that project to the issue.

Swimlane by Cross-Project Versions

When selecting Swimlanes by Type Cross-Project Versions will have an own lane. Individual project versions will be in Version lane.

Filter by Cross-Project Versions

You can also filter by project versions on the board.

Click on More to select Filter by entity types

Select filter and tag Cross-Project version.

Cross-Project Versions in Reports (Insights)

Cross-project versions behave the same way as any other version in Reports (Insights). It’s just an aggregate of Fix Versions. In Burnup and Trends reports we decided to go a bit extra mile to show cumulative graphs and per-version graphs (the same way we do for packages)

This also applicable to appropriate Gadgets.

Virtual Versions (Alternative ways of scoping releases)

Let’s come to fix versions for a second.

Practically, what Release is?

Release = all issues where fix version field equals “1.2.3“

So, basically it’s JQL.

This became a notion of what we call Virtual Versions.

At the moment we support the following types of Virtual Versions:

  • Epics

  • Sprint

  • pure JQL version

Why do we need to differentiate?

  • Similar to fix versions, epics and sprints are defined via specific standard/custom fields therefore we can add/remove Jira issues from Epic- and Sprint- based versions, we can track when items were added/removed from the versions .. thus we can have more possibilities of managing and generating insights. Pure JQL version is just a container of issues gathered by certain criteria.

Creating Virtual Versions

To create virtual versions (as any other entity in the App) click on “Add items“ button in right top corner.

“Add & Schedule” side panel will show up.

Click on either “Epic“ or “Sprint“ or “JQL version“ to create respective Virtual versions

Epic

If you click Epic we will pull all the Epics from the projects you selected for the board. We will outline

  • Epics that were already added to the board but without Start/Release Date defined so you can schedule them by clicking “Schedule“. (check out our Epics Sync functionality)

  • All other Epics that are not yet on the board so you can “Add & Schedule“ them

  • If you can’t find your epic, be aware of the paging below (or check you included all the projects to the board settings)

If you want to create a new Epic and put it to the board just click “Create Epic“.

Sprint

If you select Sprint we will automatically pull all the accessible boards from your Jira instance. Once you select one of those we will outline all the available `Sprints to add.

Sprints have Start/Release Date by definition so just click “Add“ for the sprint to show up on the board.

To create a new sprint click “Create Sprint“.

JQL Version

If you click JQL version we will automatically outline all JQL versions created on the board but not yet scheduled (no Start/Release date defined)

Click “Schedule“ to define Start/Release date for the version to show up on the board.

Click “Create Virtual Version“ to specify JQL and add a new one.

Editing Virtual Versions

Click on any Virtual Version to edit it.

Epic

Pick another Epic from look up.

Sprint

Pick another board and/or Sprint from lookups.

JQL version

Amend JQL if you need to

Changing type of Virtual Versions

If you want to change the type of Virtual Version, just select new one from the look up and specify required details for specific type of Virtual Version.

Changing scope of Virtual Versions

You can change scope only for Epics and Sprints.

Same way you do it for fix version click on the “Issues“ tab to either add a new item or pull existing to the release.

Swimlanes by Virtual Versions

On most of the views you can select the way you want to configure Swimlanes.

If you select “Swimlanes by Types“ you will get the following grouping:

  • Fix Versions

  • Epics

  • Sprints

  • JQL version

This allows you create a number of interesting views, namely:

  • Show your Releases (as fix versions) and sprints below comprising your releases. For e.g. it can be PIs and Sprints comprising PIs

  • Show your Releases (as fix versions) and flow of Epics in parallel to connect engineering deliveries and product features.

  • etc.

Filter by Virtual Versions

You can also filter by virtual versions on the board.

Click on More to select Filter by entity types

Select filter and virtual version you want.

Virtual Versions in Reports (Insights)

Virtual versions behave as any other version in Reports (Insights). Remember at the end of the day it’s just a JQL:). The problem comes with historical data (applicable to Burnups, Trends, Scope Change Report) when you need to understand the scope of version on a specific date in past. For this reasons we can’t outline Burnups, Trends, Scope Change Report for virtual versions.

This also applicable to appropriate Gadgets.

Packages (Meta Releases)

The notion of Package (or Meta Release) is to group various versions into a single business deliverable. Why business? - we believe that is most cases versions are used for software components (artifacts) to be delivered while business deliverable requires multiple components (artifacts) to be delivered plus complimentary activities performed - e.g. Backend Services, Backend-for-Frontend, Android App, iOS App, graceful rollout to 100% of the users

We allow to package any of the versions outlined above, namely:

  • Fix Versions (Single Project Versions)

  • Cross Project Versions, either by itself (as aggregate) or including encompassing Fix Versions

  • Epics

  • Sprints

  • JQL Versions

Creating Packages

In Release Management App you can either create package in line from the packages tab by putting mouse in appropriate column or via Add Items panel. In both options you can either create one from scratch or use one of predefined Templates.

You would need to complete the following properties:

  • Name

  • Description

  • Sync options

  • Epics (if any) that you want to package

  • Sprints (if any) that you want to package

  • JQL versions (if any) that you want to package

  • Cross-Project Versions (if any) that you want to package

  • Fix Versions in designated projects (if any) that you want to package. List of projects listed to what is supported by Release Board

  • Status/Column

  • Start Date

  • Release Date

if you want to create multiple items select Create another checkbox.

To create from template you would be pick one, specify start date as other dates in the templates will derive from it, use Prefix or Suffix if you want to use for all the entities in template, namely versions, their milestones, package milestones.

Editing Package

To Edit package you need to click on it on any of the views.

Here you can edit the list of versions included into the package to add/remove some.

Check to understand what else you can do with packages on the board.

Extra: Some use cases

SAFe PIs or Program-level Releases

If you practice SAFe you might create Package as PI to include

  • specific versions of software components you plan to deliver in scope of this PI

  • sequence of Sprints

  • product Epics representing major functionality that will be delivered

  • Hot Fixes or Service Release you had to work on during PI.

Hot Fixes or Service Releases

Let’s say you delivered version 1.2 of your Payment Gateway. Shortly after you realized you need to do a Hot Fix or Service Release to repair some integrations broken by the latest changes.

The recommended approach is yet another fix version with appropriate scope. But some teams are trying to avoid it as this multiplies the number of fix versions that will be used.

Instead you can create a JQL version with

fixversion = “1.2“ and labels equal “HF 1.2.3”

You can also package it with fix version so you have ultimate visibility on the core version and all Hot Fixes or Service Releases produced.

Component Releases

There are cases when multiple teams own multiple components. The best practice is to let each team own their Jira project to customize workflows according to their needs.

From there own you might have 2 strategies:

  1. Let each team do own versioning approach and cadence of release to deploy their artifacts to destination environments. In such case, Packages are ultimate solution to grab respected artifacts into business release to a) orchestrate and b) create visibility what’s included, when will be delivered and why so slow:)?

  2. Align release management / cadence across all teams. In this case would be very beneficial to make single version span across multiple projects. If you need couple of such iterations to deliver business feature you can group couple of Cross-Project Versions into a Package.