How releases get into the Release Center

[#1]

This article is part of a series on how to make your life easier by using a separate Release Center project and automations in Jira Cloud. The series will help you manage releases more efficiently and get full control over release management, achieving fully controlled releases without them falling into your lap all at once. You can read the first article about how to stop losing sleep over your releases with Release Center here. 

In this article, you will learn how to:

• create Jira Software versions automatically 
• connect Jira Service Management (JSM) change requests to the Release Center
• track versions and change requests in the Release Center

Without further ado, let's get into our topic.

Jira Software versions and releases

In Jira Software, versions represent points in time for a project. They help you organize your work by giving you milestones to aim for. You can assign issues in your project to a specific version, and organize sprints around completing work in that version. We assume you already know how to work with versions in Jira, and would like to give you some useful steps how to manage versions and releases in Jira Software automatically. 

Create a version automatically

Automation in Jira is a no-code rule builder that enables you to build if-this-then-that-rules based on events in Jira. It allows us to automate the processes, save time and keep Jira up to date. Automating release management saves the time of the project manager, release manager or lead engineer. 

To сreate a version automatically do the following:

1. Navigate to your project in Jira.
2. In the project menu, click on Project Settings.
3. Select Automations - Create Rule.

Triggers

You can choose the one working best for your chosen project release management ceremonies and practices.

Trigger	Description
DevOps triggers (use them considering you have integration with development tools)
Branch created	Related smart values:  {{branch}} Use conditions to refine the branches you are monitoring with this trigger. The rule will run when a branch is created.
Commit created	Related smart values:  {{commit}} Use conditions to refine the commits you are monitoring with this trigger. The rule will run when a commit is created.
Pull request created	Related smart values: {{pullRequest}} Use conditions to refine the pull requests you are monitoring with this trigger. The rule will run when a pull request is created.
Pull request merged	Related smart values: {{pullRequest}} Rule is run when a pull request is merged. This trigger needs no configuration. With additional conditions, you can select a repo and destination branch.
Build status changed	Related smart values:  {{build.name}}  {{build.url}}  {{build.state}}  Rule executes when the status of a build changes. You can configure this rule to only trigger on certain build names or builds associated with certain branches or tags.
Build successful	Related smart values:  {{build.name}}  {{build.url}}  {{build.state}}  Rule executes when a build succeeds. You can configure this rule to only trigger on certain build names or builds associated with certain branches or tags.
Deployment status changed	Related smart values: {{deployment.name}} {{deployment.url}} {{deployment.state}} {{deployment.environment}} Rule executes when the status of a deployment changes.
Deployment successful	Related smart values: {{deployment.name}} {{deployment.url}} {{deployment.state}} {{deployment.environment}} Rule executes when a deployment succeeds.
General triggers
Issue transitioned	The rule will run when an issue transitions from one status to another. Configure this trigger so it listens to the status of your choice, or simply any transition in your workflow.
Scheduled	This rule runs on a specified schedule. You can run the rule at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules.

The full list of triggers ready to use is available here. 

Action

As soon as the trigger and its conditions are passed, you can create a version automatically. You can control the version name and use your own naming convention if needed. 

You can also set a version start date and release date automatically. Finally, you can assign a version to the issues triggered by the rule (the ones from the pull request/commit or the associated branch). 

Example automation rule

Below is the example automation rule which can be used as a templated rule.

Rule step	Details
When: The pull request is merged	The rule is run when a pull request is merged. This trigger needs no configuration.
If: Compare two values Checks if {{pullRequest.destinationBranch.repository.name}} equals a specified repo name	With Jira automation smart values you can add a condition to check for a pull request to be merged in a specific repository.
And: Compare two values Checks if {{pullRequest.destinationBranch}} equals a specific branch name	An additional condition can be added to check for a designated branch name, for example, develop.
Then: Create a version	Creates a version with the following details: ·   Version name - mandatory ·   Start date - optional ·   Release date - optional  ·   Version description - optional ·   Project (in Jira Software) - mandatory  You can use whatever you want as a version name.
And: Edit issue fields	Edit the “fixVersion” field in all issues related to the merged pull request with the newly created version.
And: Add value to the audit log	This is an optional step. However, it is recommended to log the automation rule for easier troubleshooting.  A log message is required here, and you can log all the steps related to this particular automation rule.

Release a version in Jira Software automatically

Using the same triggers described above, you can automatically release a version. 

Please note: by default, the release version action will release the next unreleased version with the existing release date. If no date is set, the release date will be set by default to the current day. You can change the order of the next unreleased version on the Releases screen of the project. 

Also, you have control over the other options such as:

• Specific version name to release - optional
• Release date (you can also override the release date if the one is already set) - optional
• Project in Jira - mandatory

As soon as a version is released, we can trigger automatic creation of a change request, if needed, or trigger additional actions in the Release Center project. 

Here is an example automation rule which can be used as a templated rule for releasing the version automatically:

Rule step	Details
When: Issue transitioned	The rule runs when the issue status changes to Done (you can select a status corresponding to your Jira Software workflow here).
Then: Release a version	Release a version assigned to the issue triggered the rule (moved to Done)
And: Add value to the audit log	This is an optional step. However, it is recommended to log the automation rule for easier troubleshooting.  The log message is required here, and you can log all the steps related to this particular automation rule.

Connect Jira Software versions to our Release Center 

Below rule needs to be added in every Jira Software project which we are tracking the releases coming from. 

1. Navigate to your project in Jira.
2. In the project menu, click on Project Settings.
3. Select Automations - Create Rule.

Here is an example automation rule which can be used as a templated rule for creating a Release Center Epic from any (or selected) Jira Software project versions automatically: 

Rule step	Details
When: Version created	The rule is run when a new version is created. If the project follows a specific version’s naming convention, the rule can conditionally run only if, for example, the version contains PROD in its name.
Then: Create an issue	The set of fields need to be completed in accordance with the below: Project: Release Center  Issue type: Epic  Summary: Project_name: {{version.name}} Description: https://YOUR_URL.atlassian.net/projects/PROJECT_KEY/versions/{{version.id}}/tab/release-report-all-issues Start date: {{version.startDate}} Due date: {{version.releaseDate}} Epic name: Project_name: {{version.name}} Linked issues: is caused by trigger issue Additional fields:  {     "update": {         "Affected services": [             {                 "set": {                     "value": "SELECT_FROM_SERVICES"                 }             }         ]     } }
And: Add value to the audit log	This is an optional step. However, it is recommended to log the automation rule for easier troubleshooting.  The log message is required here, and you can log all the steps related to this particular automation rule.

With this rule, you can update any additional field you decide to add in the Release Center, or add links to existing Change requests in JSM (if any), or perform additional actions.  

Change requests from JSM

Change management or change enablement is a service management practice that allows you to lessen risks and interruptions to IT services and simultaneously make changes to critical systems and services. Changes involve adding, altering, or removing anything affecting services directly or indirectly. Jira Service Management offers you an out-of-the-box way to manage changes while also adhering to ITIL practices. In our case, changes are also one of the ways for the release manager to control the releases. 

Now we will demonstrate how it may work with our Release Center. 

As soon as a change is created, and it is related to a specific deployment, we create a linked Epic in the Release Center automatically. The Epic populates all the details related to the change, such as service, deployment-related information, all important dates, etc.

Below is an example automation rule providing us with this integration between changes in JSM and Epics in the Release Center: 

Rule step	Details
When: A change request is created	The rule runs every time when a new change request is created.
Then: Create an issue	The set of fields needs to be completed in accordance with the following:  Project: Release Center Issue type: Epic  Summary: {{Service Information.name}} Description:  Start date: {{Change start date.jiraDate}} Due date: {{Change completion date.jiraDate}} Epic name: {{Service Information.name}} Linked issues: is caused by trigger issue Additional fields:  {     "update": {         "Affected services": [             {                 "set": {                     "value": "SELECT_FROM_SERVICES"                 }             }         ]     } }

Feel free to populate any other fields in the Release Center Epic relevant to your specific case. 

Please, let us know any tricks up your sleeve we haven’t mentioned 🙂

We do hope these examples are helpful, and you see the benefits. Still, please stay tuned for the future articles, as we are saving the most interesting - reporting and visualisation of our easy to use Release Center for you.