Jira

Issue Tracking integration for JIRA 4 and later.

  • About
  • Details
  • Release Notes
  • Installation

JIRA and BuildMaster

Create and Transition JIRA issues as your application release moves through your BuildMaster pipeline.

JIRA is an integral tool for many organizations. With this extension, you can utilize your established JIRA workflows and process for issue tracking and build on it to a develop a more robust DevOps toolchain with BuildMaster.

Operations

Linking BuildMaster and Atlassian's JIRA provides Built-in operations that may be called in your deployment plan - creating visibility of issues associated with the release, and the ability to halt a deployment when issues are open.

Specific Issue Tracking operations added include:

  • Create JIRA Issue - Creates an issue in JIRA
  • Transition JIRA Issue - Transitions issues in JIRA from one status to another
  • Generate Release Notes - Generates an HTML file containing the BuildMaster release notes and/or issues from JIRA
  • Halt promotions when JIRA issue of a specific status exists for the specified release

Using JIRA with BuildMaster

Issue tracking is a cornerstone of the application release process and facilitates communication of specific features and issues. Integrating issue tracking, an already established process, into your DevOps toolchain is a key step deploying faster while maintaining compliance and traceability.

The steps below will outline a real-word example of how to utilize BuildMaster's JIRA extension.

Step 1: Install and Configure Extensions

First you'll need to install the JIRA Extension (version 5.6 or higher).

Administration > BuildMaster Extensions > JIRA

Then create a Resource Credential to link BuildMaster to JIRA.

Administration > Resource Credentials > Create Credential > JIRA

Next, navigate to an application to associate it with a JIRA project click on issues > Configure External Source > JIRA Issue Source and fill in the appropriate fields.

We're using the Variable $ReleaseNumber so that we can tie issues in JIRA to a release in BuildMaster without having to specify a single release.

Issues in BuildMaster should always be associated with a release. JIRA however has no concept of a release, so the JIRA issue source uses the Project and Fix for version fields in JIRA to determine which issues to pull for a particular release, you can instead use JQL if there’s a more complicated association (multiple projects, different fields, etc).

When defining an issue source, you can use configuration variables and functions such as $ReleaseNumber. When run, these will be replaced with the appropriate value; for example if you have “ABlast” as the Project name and “v$ReleaseNumber” as the Fix for Version, and you’re viewing release 2.0 in BuildMaster, then the issue source will pull all issues the ABlast JIRA project that have "v2.0" as their Fix for Version.

After manually configuring an issue source, any time you visit that application's overview page in BuildMaster, it will automatically refresh issues from that issue tracker. You can also manually refresh by going to Issues > Configure External Source > Manually refresh. Manually refershing will also provide additional information like Execution Details including execution logs.

After configuring JIRA as the issue source, the overview page of your application’s release will display all issues in JIRA assigned to that release, regardless of JIRA status.

You can also view all issues from the issues tab, regardless of release.

Step 2: Using BuildMaster and JIRA together

Configuring an issue source in BuildMaster provides more functionality than increase visibility for the development teams. Additional useful capabilities are added once an issue source is configured.

Creating a Gate

First, we can put an Issues Resolved gate at the production (or staging) stage of your BuildMaster pipeline. This gate restricts a release package from moving forward unless every issue that is assigned to that release has a specific status (Done or Closed). This serves as a final check point, ensuring that every issue associated with this release has the appropriate status. In many cases ensure that a feature or bug is Done.

This can be done at any stage of a pipeline for any status that would be appropriate. This works as a check, but doesn’t make using an issue tracker any easier. We can also automate the stages that an issue travels through in BuildMaster.

Automating a JIRA Workflow

We know that workflows in JIRA can be as simple as: create, test, close, but with JIRAs customization they can also be incredibly complex. The more complex they get the more burdensome the manual process of moving an issue through your workflow can be. But BuildMaster can help automate this manual process with a built in Operation.

The transition Issue operation allows you to set an issue’s status as part of a deployment plan.

For example if you have the above workflow in JIRA that goes Open > Checked In > Ready for Test > Approved > Closed, you can add the Transition Issue Operation to a BuildMaster deployment plan. You can use this plan to promote a package to a testing stage, and have this operation change the status from Checked In to Ready for Test automatically when the package is moved to that stage.

Visual

Text Editor (OtterScript)

This allows the testing team to either then accept the change or revert it back to Open for more work. This same process can be used to move all Approved issues to Closed as part of the deployment to the final stage if desired.

Creating a New Issue

BuildMaster also allows you to create a JIRA issue from within BuildMaster.

You can do this directly from within a deployment plan using the Create JIRA issue operation.

Visual

Text Editor (OtterScript)

As seen from within JIRA, The issue has been created.

While monolithic deployment solutions are fast becoming a thing of the past, it doesn’t mean that the tools used to deploy a modern application in a DevOps environment should be isolated either. Integrations that make sense, increase visibility, and help automate manual tasks to create a stronger DevOps toolchain that allows organizations to expand and utilize established processes.

5.6.3

1/13/2017

No notes for this release

Download (requires BuildMaster 5.6.0 or newer)

5.6.2

12/12/2016

No notes for this release

Download (requires BuildMaster 5.6.0 or newer)

5.6.1

12/8/2016

No notes for this release

Download (requires BuildMaster 5.6.0 or newer)

5.6.0

11/18/2016

No notes for this release

Download (requires BuildMaster 5.6.0 or newer)

5.1.0

6/17/2016

No notes for this release

Download (requires BuildMaster 5.1.0 or newer)

5.0.0

4/29/2016

No notes for this release

Download (requires BuildMaster 5.0.0 or newer)

4.4

1/5/2016
  • 4 - Support for JIRA v7

Download (requires BuildMaster 4.9.5 or newer)

4.3

1/5/2016
  • 3 - BuildMaster 4.9 Compatibility
  • 2 - Change Issue Status Support

Download (requires BuildMaster 4.9.5 or newer)

4.2

6/2/2015

No notes for this release

Download (requires BuildMaster 4.7.0 or newer)

4.1

7/18/2014
  • 1 - Do not log error when fixVersion is not found

Download (requires BuildMaster 4.3.2 or newer)

4.0

9/14/2013

No notes for this release

Download (requires BuildMaster 4.0.0 or newer)

3.2

1/18/2013

No notes for this release

Download (requires BuildMaster 3.5.0 or newer)

3.1

11/1/2012
  • BMXJIRA-1 - Improve Error Messages on Create/Close Release

Download (requires BuildMaster 3.0.0 or newer)

3.0

1/7/2012

No notes for this release

Download (requires BuildMaster 3.0.0 or newer)

If your installation of BuildMaster can access inedo.com, simply navigate to Admin > Extensions, and install or update extensions from the gallery.

You can also manually install the extension.

  1. Copy the extension file (Jira.bmx) to the Extension Library path (by default, this is c:\BuildMaster\Extensions).
  2. Restart the BuildMaster Service (Admin > Service).
  3. Restart the BuildMaster Web Application (Admin > All Settings > Save).
  4. Verify that the new extension has been loaded (Admin > Extensions)