Managing Packages on Release Board
Topics
- 1 Topics
- 2 Any Tab/View … Same Package
- 3 Packages View
- 4 Common Operations with Packages
- 5 Package Workflow
- 6 Package Details dialog
- 6.1 Summary
- 6.1.1 Projected release date (PRD) & release delay duration
- 6.1.2 Scope statistics
- 6.1.3 Comments
- 6.1.4 History of transitions
- 6.1.5 Changes history
- 6.1.6 Actions
- 6.2 Milestones Tab
- 6.3 Dependencies Tab
- 6.4 Scope Tab (former Issues)
- 6.5 Compass
- 6.6 Commits/Deployments
- 6.1 Summary
- 7 Manage Versions in the Package
- 8 Packages as swimlanes for versions
- 9 Deploy Package to Environment
- 10 Automation for Packages
- 11 Bulk move versions in the package
- 11.1 Automation trigger
- 12 Multi-select and other bulk operations
- 12.1 Compare packages
Any Tab/View … Same Package
We have different tabs/views in the App to outline packages and packages are depicted also differently, namely
as Card on Packages view in specific Column/Status (read how to configure Configure Release Board Settings | Card layout)
as Swimlane on Board view for versions if Swimlanes by Packages are selected
as Bar on Roadmap view according to Start/Release Dates. Independently on accompanied by encompassing versions if Swimlanes by Packages are selected
as Event on Calendar view according to Release Date
as Row on List view. On it’s own or as a group of encompassing versions if if Groups by Packages are selected
But apparently this is same Package an clicking on it will open up same Package Details dialog
Packages View
Packages view is designated to manage packages and track progress according to packages workflow defined. It’s organized by Columns (Statuses / Workflow Steps). Read more below what are capabilities are there for you to manage packages.
Common Operations with Packages
Creating & Editing Packages
Please refer to Release Anything (or Taxonomy of Releases) section of this documentation to understand how to create packages from scratch or view templates.
Clone Package
In addition to creating packages from templates you can clone existing one. All the versions, their milestones and package milestones will be cloned. To do so
either right click on on the package to select “Clone“
or from package summary page select Action > Clone
A confirmation popup will show up where you define Prefix that will be propagated to new package name and all encompassing version names (if selected)
If you check “Clone version“ option all versions associated with the package will be cloned.
It means that new empty Fix Versions will be created in the same projects and duplicates of Virtual Versions will be created consisting on same issues.
Otherwise, existing versions will also reference a cloned package.
Archive Package
The user can Archive and Unarchive packages from the popup menu, by right-clicking:
The packages on the board may be filtered by Archived / Unarchived flag:
In a situation where both archived and unarchived packages are shown on the board, archived packages will be "grayed out" and an “ARCHIVED” label will appear in the right top corner. Archived packages may be moved to another column or edited without any restrictions.
Archived package
Unarchived package
Delete Package
Users can delete a package from the board. In order to do so, right click on the package and choose "Delete" option:
Tagging Packages
Read more about Tags for Packages and Versions
Package Workflow
Configure package workflow
To define or adjust package workflow please navigate to Configure Release Board Settings | Manage package workflow section of this documentation. You need to be one of the Administrators to do so.
Change package status and order
You can drag-and-drop packages between columns to change their status and reorder inside one column.
Package Details dialog
Summary
By clicking on a package on the release board the Package Details dialog is shown. By default, “Summary” tab is displayed. For all the future occurrences the system will remember your last tab and navigate you to it.
You can view and update the following package fields using inline editing:
Custom color (if configured)
Name
Description
Alternative Description (via Custom Properties of Paragraph Type)
Versions
Tags (Tags for Packages and Versions )
Status/Column
Start date
Release date
Projected release date (if configured)
Custom Properties (read more)
On the top`right corner of the dialog you can see an icon to copy deep link for the versions to use externally. also ability to zoom in/out dialog if you have a lot of data.
Projected release date (PRD) & release delay duration
Projected release date and the release delay duration in days is calculated based on package start date (SD), release date (RD) and issues statistics.
When package is delayed the “Release date” is highlighted with red color and the delay duration in days is displayed next to it.
Package PRD
Package PRD is calculated in cases:
All versions in the package have PRD or RD (Each particular Version will have PRD or RD)
Package PRD equals latest RD or PRD of all versions in the package
Package delay status
The package is considered as delayed in two cases:
Package RD is not empty and in the past
Package RD is not empty, calculated and PRD > RD
Package delay duration
Package delay duration in days is shown if the package is delayed (see above) and package RD is not empty.
|
Scope statistics
Issues statistics is a “Progress Widget” that shows the number of issues by corresponding statuses - To Do, In Progress and Done - as they defined in issues workflows.
For calculating data for the widget we took the same approach as Atlassian calculating Version Statistics Page in Jira Releases. So you should expect to see pretty much the same data.
By clicking on any of the statistic numbers you will be automatically redirected to “Issues View“ with the appropriate filter applied to review corresponding issues list.
Comments
You can leave comments for any package in rich text format to share some details or insights with your team.
You can also Edit it if you made some typoo or delete completely.
History of transitions
You can see an audit trail of all transitions, namely who and when made the move.
Changes history
Similar to transitions history “changes history“ tab outlines all the changes performed to package, the date and the user performed the action.
Actions
From package summary view you can trigger certain actions, namely:
View on roadmap. You will be redirected on roadmap view and your selected version or package will be highlighted.
Release Notes. You will be redirected to release notes screen to select appropriate template for your package and generate your notes.
Other actions. Delete, Archive and Bulk Move versions under the package
Reports. Choose one of the reports you want to generate for your package.
Milestones Tab
In addition to custom workflows for versions and packages, Release Management app allows to create intermediate milestones for both that could be
either linked to accomplishments of certain steps in workflow
or other important check-ins, not necessarily connected with workflow steps
Once specified for versions and/or packages, milestones will be outlined on Roadmap view (incl. Gadgets) as well as become input parameters for Burnup and Trends Reports (incl. Gadgets).
For more details please navigate to Milestones "on the way" section of this documentation.
Dependencies Tab
Navigate to Release Dependencies section of this documentation to learn more about Packages inbound and outbound dependencies.
Scope Tab (former Issues)
You can browse all the issues linked to all the versions comprising the selected package on the Scope tab of Package Details dialog.
The functionality of the view replicates identical views for the versions combined. Since package can contain versions from different projects there are some differences as well, namely:
you also have Project in default fields configuration
and Projects filter in filters ribbon
You can define default fields configuration for versions and packages separately: - Configure Release Board Settings | Default Scope Columns.
The rest of functionality is identical to Versions Scope view: - Managing Versions on Release Board | Scope Tab (former Issues)
Compass
If you use a notion of Component versions and use Atlassian Compass following Atlassian Compass Integration section of this documentation. Classical (project bound components) will be supported shortly.
Commits/Deployments
Git, Bitbucket, CI/CD tools Integrations
Manage Versions in the Package
Create new, Add existing or Remove versions from the package
Fix Versions
All versions that have been already added to the package are displayed and grouped by their projects.
Users can add new version from already selected projects or add a new project add appropriate version.
Users can also create a new version in any of selected projects and add it to the package provided that User has “Project Administrator” permissions in that project.
Cross-Project Versions
You can add single of multiple Cross-project versions to the package. To do so click on the package find appropriate row on summary tab to add/delete items from the list.
Virtual Versions
We have designated lists for each virtual version type to include into the package. Thus, you can list
Epics
Sprints
JQL version
you would like to add to/remove from the package.
Synchronizing versions in the package
Before we brought pure Cross-Project Version the recommendation was to create a“dummy“ package and sync versions inside to emulate “Single Version“ solution. Now, with Cross-Project Versions Names, Descriptions and Start/Release Dates are automatically sync’d.
Therefore, packages are now used for packaging multiple artifacts into complex/program-level releases.
Still sync functionality is there if you want to sync all encompassing versions and decide what fields to sync.
If cross-project version is included or one of fix versions that sits with cross project version included into the synching process it will sync all the rest linked fix versions.
Versions sync functionally allows to update automatically some of key parameters of all package encompassing versions, namely:
Name
Description
Start date
Release date
To enable it click on "Synchronize versions" toggle while editing the Package.
As a result all the included versions names, descriptions and dates will be aligned. From this moment on all the changes to Release details will be automatically propagated to all the included versions.
Customize synchronization
In case you want to sync only sub-set of the fields please click on configuration icon close "Synchronize versions" toggle to specify exact fields you want to sync now and alert on being "not-in-sync"
Alert for versions not-in-sync
If "Synchronize versions" toggle is turned on the App will identify any change happening to corresponding versions and notify you next time you open Release dialog about versions not being in Sync.
Once you click on "Synchronize " all the versions will be yet again synchronized.
Packages as swimlanes for versions
On Board, Roadmap and List views you can setup Swimlanes/Groups by Packages. We find it extremally useful as it helps to understand the progress with Package as a whole and encompassing versions on a single view. To add smth in the mix you can also turn on dependencies to get an ultimate view on 2 key questions - 1) When? and 2) Why so slow?
Deploy Package to Environment
You can assign environments to all or subset of the versions comprising a package in Bulk. To do so
either right click on package and select “Add environment“
or from package summary page choose “Add environment“ from list of options on the right
Once selected you will see a dialog showing all existing assignments of the versions comprising a package and their environments.
You can change build number if you like or delete version from environment.
To add new environment select one from drop down at the bottom.
By default all of the package versions will be added to new environment.
You can amend build numbers and leave only the versions you want to deploy.
Automation for Packages
Read more about Release Automation Explained to create automation rules for packages with various triggers, conditions and actions.
But there are also some hard coded rules in the App, namely:
Auto-complete package
Once you move the last UNRELEASTED version into RELEASED state the App will suggest to move entire package into one of “Done“ columns automatically.
You can skip it by clicking “Cancel“.
Bulk move versions in the package
You can move all the versions of the package into specific status/column in Bulk. Right click on any package to choose “Move versions“.
choose the destination column on the versions board
you can also filter the specific versions you want to move per projects
as well as specific virtual versions as well.
Upon “Move“ all the versions will be updated moving to specific state of the workflow.
The functionality is also available via package summary screed, in “Actions“ menu
Automation trigger
You can tie bulk version move with specific status change of the package. Open board settings and navigate to “Packages workflow“.
Check the status that should trigger the versions move dialog to appear.
Multi-select and other bulk operations
With Ctrl+ users can select multiple packages on the board. Thus they can move them to destination column all together:
Once multiple packages are selected right click on any of them provides a list of available bulk operations. At the moment we support:
bulk version move
bulk archive
and bulk delete
compare packages
Compare packages
Once you multi-select packages you can use the option to compare them
On the diff screen you have flexibilities to select grouping options, namely by:
Project - Jira projects selected for Release Board
Tag - tags defined for packages/versions in the App
To show unique difference, select “Show difference“ only toggle.