Configure Release Board Settings

Owned by Yuri Kudin
Last updated: Mar 05, 2024 by Yuri
13 min read

In order to navigate to the Board’s Admin Page, click on the Settings button in the top right corner of the release board or select Settings from the actions list on the Release Boards Page.

image-20240305-095507.png
image-20240305-095541.png

General Settings

On the General section an administrator can:

  • change the board name

  • manage Administrators list (at least one should be specified)

  • add or remove projects from the board

  • outline visibility of the board for different users and groups

  • toggle on/off Projected Release Date (PRD) functionality

  • configure Epics Scheduling (if required)

  • defined color coding rules

The following sections outlines this in details.

Projects on the board

You can add projects to the release board and/or remove them. All Versions from selected projects are displayed on the board. 

Project picker outlines only the projects where current user has “Browse project” permissions. Otherwise, the project will not be available from the list. The same logic is applied to all other projects on the board that have already been added to the board by other users.

Projected Release Date (PRD)

The toggle turns on/off Projected Release Date and Release Delays functionality.

Read more details about how this functionality works here:

Epics Synchronization

We operate we a number of release entities (types) and Epic is one of them. FixVersions/Versions/Releases as well as Sprints have predefined start/end (release) dates that we use through the App. Unfortunately, Epics do not, therefore Advanced Roadmaps and other 3rd party roadmapping products are using different custom fields that are not aligned.

To give our clients ultimate flexibility and let use Release Management together with other Apps we allow to choose Custom Fields for Start and Release dates.

Hide Outdated Releases

You can automatically hide releases that have not been update for sometime. The following time intervals are supported:

Color Coding for Releases

You can configure color coding for cards on the board and bars on the Roadmap and Calendar. Most of options are based on release workflow state or release scope progress.

The rules are the following:

Version (Fix Version)

  • By Board Column Status (Default)

    • Blue - Unreleased

    • Green - Released

  • By Progress

    • Green >90% are Done

    • Yellow >20% are Done

    • Orange >5% are Done or “in progress” !=0

    • Grey - 0% done

  • Custom (see below)

    • Grey by default

    • with option to select custom color coding for individual Fix Versions

Epic

  • Board Column Status (Default)

    • Blue - Unreleased

    • Green - Released

  • By Epic Status

    • Status Category (Todo, In Progress, Done )

  • By Progress

    • Green >90% are Done

    • Yellow >20% are Done

    • Orange >5% are Done or “in progress” !=0

    • Grey - 0% done

  • Custom (see below)

    • Grey by default

    • with option to select custom color coding for individual Epics

Sprint

  • Board Column Status (Default)

    • Blue - Unreleased

    • Green - Released

  • Sprint Status

    • Grey - Not Started

    • Blue - In Progress

    • Green - Done

  • By Progress

    • Green >90% are Done

    • Yellow >20% are Done

    • Orange >5% are Done or “in progress” !=0

    • Grey - 0% done

  • Custom (see below)

    • Grey by default

    • with option to select custom color coding for individual Epics

Virtual Version

  • Board Column Status (Default)

    • Blue - Unreleased

    • Green - Released

  • By Progress

    • Green >90% are Done

    • Yellow >20% are Done

    • Orange >5% are Done or “in progress” !=0

    • Grey - 0% done

  • Custom (see below)

    • Grey by default

    • with option to select custom color coding for individual Epics

Package

  • Board Column Status (Default)

    • Grey - Todo

    • Yellow - In Progress

    • Green - Done

  • By Progress

    • Green >90% are Done

    • Yellow >20% are Done

    • Orange >5% are Done or “in progress” !=0

    • Grey - 0% done

  • Custom (see below)

    • Grey by default

    • with option to select custom color coding for individual Epics

Custom color coding

If you select Custom in any of the dropdowns all the release items of selected category (Fix Versions, Epics, Sprints, JQL versions) will be color by default in Grey. But this turns on the flexibility of coloring individual release items with the pallet you like (similar to Epics in Jira).

To do so click on release item to show details popup. Close to the name you will see a pallet with an option to pick up a custom color.

Permissions Management

There are three levels of Apps permissions, namely 

  • Global Permissions,

  • Board Administration,

  • Board Manage & Readonly Permissions.

Global Permissions

Global permissions are created automatically when installing the App. There is ongoing issue with Atlassian when on some sporadic cases Global permissions are not properly populated. In this cases, no one can access the App and Jira Global Administrators need to configure it manually.

Read more about https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/92143812/FAQ+Troubleshooting+the+App#Can%E2%80%99t-see-%E2%80%9CRelease-Management%E2%80%9C-in-Apps-section

If you do not see the App in Apps menu please contact your Jira Global Administrators to configure Global permissions manually to add you or/and group you are part of to the settings.

Board Creation Permissions

Coming soon

Global permissions are good to decide who can view/access the application. But once you can view/access you can create any Release Board with Projects that are available to you in order to manage releases. Some companies want to restrict such flexibility to have a limits subset of approved release boards. Therefore, we created a special permission - [Release Management - New Release Board Creation] - that allows to specify users/groups that could create boards in Application.

 

Classic Components Management Permissions

In Jira by default Components belong to Projects and could be managed by Project Admins only. This overcomplicates cross-project component management. Therefore, most of the Partner Apps that have a functionality for cross-project component management are making all the changes in App-context allowing to override Project Admin permissions.

To give Jira Global Administrators control over it we created a special permission - [Release Management - Global Classic Component Management] - that allows to specify users/groups that could change Components from Release Management w/o being Admin for corresponding Jira Projects. The scope of such permission applies only to the projects listed for the board.

 

Board Administration Permissions

Board Administrators are able to manage the board and change its configuration. It is possible to add a number of Administrators to the board by mixing individual users and groups. 

Global Jira Administrators have administrative access to each release board by default. It doesn't matter if they are explicitly added to the board as Administrators, or not.

The Board Administrators can delete themselves from the list unless there is at least one active Administrator remaining in the list. If user tries to delete the last remaining Administrator of the list the warning message will appear preventing this action to happen.

Board Manage & Readonly Permissions

Manage & Readonly board permissions are granted by using the "Permissions" section of board configuration. Board Administrators and global Jira Administrators have board manage permissions by default.

If the user has Manage & Readonly board permission but does not have Browse Project permission  - versions from those projects will not be shown on the board. In that case, the user will see a warning next to the board name:

The difference between Manage & Readonly board permissions is the following:

  • Manage means you can manipulate versions, packages, environments, release notes templates on the board (aka creating, changing, add/remove scope, deleting, archiving)

  • Readonly means you can only view versions/packages on the board without ability to process them thru the workflow, change scope, assign environments, etc. But you can generate release notes using existing templates, view environments the versions deployed to, get insightful reports, etc.

There are three way to assign Jira Users Manage, Readonly permissions

  • Users of projects in board 

    • This option grants Board Manage, Readonly permission to all users who have permission to view projects added to the board. 

  • Users of projects

    • Board Manage, Readonly permission is granted to all users who have permissions to browse selected projects. 

  • Users and groups

    • Board Manage, Readonly permission is granted to specified Jira Users and groups.

Manage Package Workflow (Transitions and Restrictions)

 On the Package workflow screen the Board Administrator can:

  • Customize a package flow by adding or removing columns on the board.

  • Rename columns.

A new column is added at the bottom of the columns list. 

Manage columns

It is possible to perform the following action with columns:

  • Update column name.

  • Delete column.

  • Change column order.

 

Change name, status or delete a column

Column name may be changed by using in-place editing within the table. These changes will be saved automatically after finishing the update.

The column will be deleted by click on "Delete" button.

If a column contains at least one package it will not be possible to delete it. In order to delete the column, you will need to move all packages from the column before taking this action.

Manage transitions

Auto-generation of Release Notes

You can also trigger automatic release notes generation for package upon move to specific column

To do so click “Manage“ for the column and turn on “Trigger Release Notes generation“. You would need to pick up one of the Release Notes templates for packages.

Package and Versions workflows sync

If you want to move all corresponding packages into specific column upon package move you can select this option in “Manage“ popup.

Restrictions

You can restrict transition from one column to another by specifying two additional checks, namely:

User/Group Restrictions

Outline only specific users and/or groups that are allowed to make the move. E.g. only Compliance team can move packages from “Ready for Compliance Review“ to “Ready for Delivery“.

JQL based Restrictions

Define a custom JQL that will be executed upon issues comprising the package and specify conditional clause from transition. E.g. all Epics should be “Ready for Development“ before package moves to “Ready for Development“. Or there should be Zero bugs before package moves to “UAT“.

Properties in JQL based Restrictions

Once configured Properties can be used in Restrictions definition, namely you can include custom properties in JQL you are using to define restriction. For Packages Workflow only Properties with type=Package could be used.

Restrictions by Properties (Validation by Properties)

You can also restrict transitions by validating some properties

Ask for Property upon Transition

While you are validating by property upon transition you can ask for property to be populated if it’s empty.

Custom restriction messages

You can now define custom error messages on workflows restrictions. You can also segregate it between permission restrictions and JQL restrictions.

Versions Workflow (Transitions and Restrictions)

On the Versions workflow screen, the Administrator of the Board can:

  • Create/update/delete version workflow statuses (aka columns).

  • Change the mapping between columns and standard Jira version statuses.

A new column is added at the bottom of the columns list.

Manage columns

Columns represent statuses of release version workflow. The following actions are allowed upon Board Administrator permissions:

  • Update column (status) caption.

  • Update mapping to Jira standard status - Released/Unreleased.

  • Delete column.

  • Change column order (sequence of steps in the release process).

 

Change name, status or delete a column 

Column name or mapping to Jira standard status could be changed using in-place editing in the table. The changes will be automatically saved after completing the update.

The column will be deleted by clicking on the "Delete" button.

 

Limitations

  • In cases where the column contains at least one version,  it will not be possible to change the column status or delete it. In order to delete or change the column, please move all versions from the column before implementing this action (Deletion).

  • It is not possible to change the column status or delete default columns, marked by icons: “blue” and “green” I-icons 

 

Reorder columns

Re-ordering of Columns can be done using drag-and-drop.

Columns are equivalent of steps in your Release Management process, so by changing the order of the columns you automatically changes the sequence of the process steps.

Manage transitions

Auto-generation of Release Notes

You can also trigger automatic release notes generation for version upon move to specific column

To do so click “Manage“ for the column and turn on “Trigger Release Notes generation“. You would need to pick up one of the Release Notes templates for packages.

Restrictions

You can restrict transition from one column to another by specifying two additional checks, namely:

User/Group Restrictions

Outline only specific users and/or groups that are allowed to make the move. E.g. only Compliance team can move version from “Ready for Compliance Review“ to “Ready for Delivery“.

JQL based Restrictions

Define a custom JQL that will be executed upon issues comprising the version and specify conditional clause from transition. E.g. all Epics should be “Ready for Development“ before version moves to “Ready for Development“. Or there should be Zero bugs before version moves to “UAT“.

Properties in JQL based Restrictions

Once configured Properties can be used in Restrictions definition, namely you can include custom properties in JQL you are using to define restriction. For Versions Workflow only Properties with type=Version could be used.

Restrictions by Environments

For versions only you can also configure restrictions by Environments. Thus, you can check whether the version was deployed where you expect it prior to move.

Restrictions by Properties (Validation by Properties)

You can also restrict transitions by validating some properties

Ask for Property upon Transition

While you are validating by property upon transition you can ask for property to be populated if it’s empty.

Custom restriction messages

You can now define custom error messages on workflows restrictions. You can also segregate it between permission restrictions and JQL restrictions.

Release Automation

By clicking on Release Automation you will see a table with all Automation rules configured/created.

The following rules characteristics will be depicted:

  • Rule name

  • Scope (Version/package)

  • Status (Active/Suspended)

  • List of Triggers

  • List of Conditions

  • Latest History status (Success/Failed)

To Create rule click on “Add rule“ button. To copy or delete rules select appropriate action items on the right.

For more details about Automation navigate to designated section of this documentation: .

(Deprecated) Webhooks

Custom Properties

Version Defaults (Version Templates)

You can configure version defaults so all your new versions created will be pre-populated with default naming convention, some basic description and list of predefined milestones.

Click on board settings and open “version defaults” section

Here you can defined default name. This a good fit if you use some common naming conventions across the org. Also basic description could be added or some kinf of template for description that people need to fulfil.

Also you can add a list of pre-defined milestones if you have some standard ones for your versions workflow management. Milestones dates are set as +/- offset from the start date of the version to be created.

Once configured the date will be pre-populated when you create a new version …

We also have “Package defaults” in a form of .

Card Layout (Board View)

Standard Fields

You can configure what standard fields you want to show on the card for Versions and Packages. Here’s a list of fields to turn ON/OFF.

Custom Fields

You can also define what custom fields you want to show on the card for versions and packages separately. Please find more details at .

Default Columns (List View, Scope View)

List View

You can define what default columns (standard fields and/or ) will be shown on List view.

Scope View

You can define what default columns (standard and/or custom fields) will be shown on Scope tab. You can do it for Versions and Packages separately.

Once user makes changes on the scope tab to create own preference … default configuration will be overwritten for that specific user and stored in his/her storage.

Good to propagate some custom fields and/or additional taxonomy onto scope tab.

Blackout Periods (Non-working Days)

Configurations

In “Non-working Days“ section of Board Configuration you can setup backout periods.

To create one put the name you would like to use in the hints, start/end date and one of suggested colors from the pallet. The periods could not be overlapping.

We support inline editing so to amend click on any property of existing period in the grid to change.

To delete period click on delete button on the right. You would need to confirm before blackout period will be permanently deleted.

Roadmap and Calendar views

Once configured in board sessions backout periods will be shown on Calendar and Roadmap view using the shades of the colors picked up. Once you put the mouse on the day caption a tooltip with backout hint will be show.

Same functionality is available in Roadmap and Calendar gadgets.