Service and change management tools are a vital part of the software delivery process, providing an efficient and auditable way to manage changes and track incidents. FlexDeploy has out-of-box integrations with popular service management tools like ServiceNow, BMC Helix Remedyforce, Freshservice, and Jira ITSM. FlexDeploy also has an option to easily create a custom integration for any providers we don’t offer native integration with.

In this article, I will go through some complex requirements made simple with FlexDeploy’s change management framework for Jira ITSM. These examples are shown at a high level, so take a look at the change management documentation for more detailed steps on setting this up on your own.

Pipeline Definition and Other Setup

Here’s the pipeline I’m using to automate the software delivery process across my environments. In this case, it is a simple pipeline with three stages, or environments.

Pipeline Definition

FlexDeploy offers flexibility in how your change management tool fits into your pipelines. This particular pipeline integrates with Jira ITSM for production approvals and for incident management.

The Custom Gate

The custom gate configured in production (shown below) takes care of setting the related ticket field per package based on the package name. In the release, my project packages will be named by their change ticket, so I don’t have to manually enter the associated change ticket elsewhere during release execution.

Custom Gate set up

The External Approval Gate

This external approval gate in production (shown below) will block deployment until all the tickets linked from the previous custom gate are approved in Jira ITSM.

Jira ITSM External Approval Gate

A ticket is considered ‘approved’ based on the approval check script on the CMS instance. Mine (shown below) waits for the status to reach ‘Awaiting implementation’ and also waits until the implementation start time.

import java.util.Date;
import java.util.TimeZone;
import flexagon.ff.common.core.utils.FlexDateTimeUtils;

// custom fields for start and end times
StartTime = TICKET.fields.customfield_12509;
EndTime = TICKET.fields.customfield_12510;
 
if (TICKET.fields.status.name == 'Awaiting implementation' && StartTime != null && EndTime != null)
{
    Date start = FlexDateTimeUtils.stringToDate(StartTIme, "yyyy-MM-dd HH:mm:ss", TimeZone.getTimeZone("GMT"));
    Date end = FlexDateTimeUtils.stringToDate(EndTime, "yyyy-MM-dd HH:mm:ss", TimeZone.getTimeZone("GMT"));
    Date now = new Date();
    if (now.after(start) && now.before(end))
    {
      return true;
    }
}

return false;

The Webhook

Lastly, I have a webhook configured to create an incident on deployment failures to production, so that the relevant users will be informed and the incident can be resolved as quickly as possible.

The webhook takes relevant information from the workflow failure event payload to provide details in the incident that will be created. The listener filters for only failed workflow deployments in production. The webhook listener script is shown below.

def listenerName = "Create incident on workflow failure";
LOG.info("Running listener: ${listenerName}");

def wfReqId = EVENT.payload.workflowRequest.workflowRequestId;
def cmsFields = [:];
def projectName = EVENT.payload.project.projectName;
def projectId = EVENT.payload.project.projectId;
def packageName = EVENT.payload.packageName;

cmsFields.put("fields.summary", "Production deployment failed for ${projectName} - package ${packageName}");
cmsFields.put("fields.description", "http://fdtlt07.flexagon:8000/flexdeploy/faces/projects?objecttype=Project&projectid=${projectId}&projectname=${projectName}");
cmsFields.put("fields.issuetype.name", "[System] Incident");
cmsFields.put("fields.project.key", "FLXDPLTSM");

LOG.fine("Creating Jira ITSM incident ${cmsFields}");

def cmsService = FLEXDEPLOY.findCMSService("JIRAITSM", null);
def cmsObject = cmsService.createIncident(wfReqId, cmsFields);

LOG.setMessage("Created incident ${cmsObject.getNumber()}");

Trying It Out

Now, we’re ready to see this process in action!

I have one package, FLXDPLTSM-37, in my release. I have created a snapshot, which is a collection of project and package versions that will run through the pipeline as a unit.

Currently, this snapshot has already completed execution through the development and QA environments, and is waiting for approval in the production environment. The related ticket has been linked from the custom gate in production.

Now, I just need to wait until this ticket is considered approved in Jira ITSM based on its status and implementation window.

Current Status of Execution

After the ticket is approved, I can see my snapshot began executing the defined steps in the production stage, starting with the deployment. For this scenario, I have set it up to fail to show an incident creation.

In addition to receiving an email notification I configured for the failure, I can also see from the webhook messages screen that it created incident FLXDPLTSM-44. This provides assurance that the right people will be alerted in a timely manner for deployment failures and have a simple way to track those incidents and their progress.

Successfully created incident

Production deployment failure notification

In Review

In this blog, we went through a few common integration points for service management with FlexDeploy, which is available with Jira ITSM. Keep in mind the scenarios highlighted in this blog are only a preview of what’s possible with this integration.

Check out our Service Management Integration blog series for a more thorough review of possible use cases.

 

Share this:
Emily Simon

In my current position at Flexagon, my focuses are FlexDeploy development and working with customers on their FlexDeploy implementations. I enjoy getting to learn more every day about this constantly evolving field and am excited to gain more experience in DevOps and application development.

More posts by Emily Simon
    

Leave a Reply

Your email address will not be published. Required fields are marked *