Release Anything (or Taxonomy of Releases)
Topics
- 1 Flexible Release Taxonomy
- 2 Single Project Versions (Fix Versions)
- 3 Cross Project Versions
- 4 Virtual Versions (Alternative ways of scoping releases)
- 4.1 Creating Virtual Versions
- 4.1.1 Epic
- 4.1.2 Sprint
- 4.1.3 JQL Version
- 4.2 Editing Virtual Versions
- 4.2.1 Epic
- 4.2.2 Sprint
- 4.2.3 JQL version
- 4.3 Changing type of Virtual Versions
- 4.4 Changing scope of Virtual Versions
- 4.5 Swimlanes by Virtual Versions
- 4.6 Filter by Virtual Versions
- 4.7 Virtual Versions in Reports (Insights)
- 4.1 Creating Virtual Versions
- 5 Packages (Meta Releases)
- 5.1 Creating Packages
- 5.2 Editing Package
- 6 Extra: Some use cases
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
Custom release workflows (Managing Versions on Release Board)
Support for Classical Components and Atlassian Compass Integration
Own inventory of Inventory of Environments
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 Managing Packages on Release Board 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:
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:)?
Align release management / cadence across all teams. In this case Release Anything (or Taxonomy of Releases) | Cross Project Versions 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.