IT Operations and DevOps teams often use separate platforms for tracking their work. Integrating these separate platforms together provides values. Teams are more efficient in keeping statuses in sync. This blog series provides an example of how to integrate these two platforms. For our ITSM platform we use Ivanti Service Manager (ISM). For our DevOps platform we use Jira Software.
Review
In the last blog, we built the automation for tracking attachments added to releases in ISM and issues in Jira. Attachments are useful in issue tracking throughout the issue’s lifecycle. In addition to building the automation, we demonstrated how adding an attachment to ISM or Jira triggers the web service scripts in ISM to push or pull it to or from Jira, respectively.
In case you missed the other blogs in this series:
We will finish off the integration between Jira and ISM by building the component that tracks sprints. The main difference is that sprints can only be created and organized from Jira then reflected in ISM, not the other way around. Like in Part 4 blog on attachments, we will be using a webhook to trigger an automation rule.
Before we jump in, let’s do one final review of the blog series goal and an overview of the lab buildout.
Overview
The integration between ISM and Jira allows for seamless communication. It automatically creates a corresponding ticket for the reported issue in the opposite platform. Removing the extra steps of recreating and filling out the details of the issue a second time eliminates potential human error and saves time. The synchronized reflection of data between the two systems makes it easy for stakeholders such as developers, administrators, and auditors to track software issues in ISM throughout the software development lifecycle as they change statuses in Jira.
Jira issues are represented as releases in ISM. Attachments providing insight into the issues can be added from either end; issues can be organized into sprints from JIRA to support agile or scrum software development. In Part 5, we will set up tracking of sprints in ISM. It is important to know that sprints cannot be created by a user in ISM. The integration is only setup to have sprints be created, organized, and started from Jira.
The process diagram below outlines the workflow for the two systems and the final prototype deployment:
Lab Overview
To support this blog, I have provisioned the following lab components:
Ivanti Service Manager-Cloud: ISM is an IT service management software: a help-desk application for submitting IT service requests, reporting issues with applications or equipment, and getting status updates.
JIRA Software-Cloud: JIRA is an issue and project tracker used by development teams for use as an organized to-do list that follows each task through development, testing, and resolution.
PostMan: PostMan is a tool used for API development. It offers the ability to collaborate, and easily build or dissect APIs.
Sprints in Jira
Sprints are organized and started from Jira and cannot originate from the ISM side. The developer team most commonly works out of Jira to determine sprint workloads, so it is not effective to organize sprints from ISM.
Once issues have been added to a sprint and the sprint is started by a user, a webhook is triggered.
The webhook kicks off an automation rule.
The automation rule makes a POST, a PUT and a PATCH web request to ISM.
- The POST creates a sprint release in ISM.
- The PUT sets the Sprint RecID for the Issue Releases in ISM.
- The PATCH links all related issues to the sprint release in ISM.
WebHook
The chaining of the webhook and automation rule is required because Jira automation rules do not currently support being triggered by a sprint starting. Let’s start with configuring the webhook.
1. In the System Settings click on Webhooks (under Advanced) in the left-hand navigation list.
2. Click on Create a WebHook in the upper right.
3. Give your webhook a relevant Name and a Description.
4. Next, we need to go into our automation rule, “Lab Sprint Started”, and click on the When: Incoming webhook component.
5. Click Regenerate then click Copy URL to copy the webhook URL to your clipboard.
6. Back in your webhook for starting a sprint, paste the URL we copied in Step 5 into the URL field.
7. Scroll down to Jira Software related events and under Sprint select started.
8. Click Create at the bottom of the page to complete your webhook configuration.
You’ve successfully created the trigger for automating communication about sprints. Next, you’ll have to update the Lab Sprint Started automation rule.
Automation Rule
If you have been following along since the beginning of the series, you should already have imported the automation rule “Lab Sprint Started”. If you don’t already have the automation rule imported you can find the .json for it here:
1. Navigate to your automation rules and select the “Lab Sprint Started” rule for editing.
2. In the POST web request, update the Webhook URL with your tenant URL and the Header with your ISM API key.
3. In the PUT web request component, update the Webhook URL with your ISM tenant URL.
4. Enter your API key in the Headers section.
5. Update the Custom data with the field ID for sprints (i.e. If the field ID for a sprint were 10020 {{issue.customfield_SPRINT_ID}} would become {{issue.customfield_10020}}).
6. In the PATCH web request, fill in the URL with your ISM tenant URL, and replace ISM_SPRINT_RECID_ID and ISM_RECID_ID with the field IDs for ISM Sprint RecID and ISM RecID fields, respectively.
7. In the Headers section add your ISM API key.
8. Save and publish the automation rule.
Test Pushing a Sprint to ISM
To test this portion of the integration you will need any issues that you are adding to the sprint to have corresponding releases in ISM.
I’ll create a new sprint and add two issues that both have corresponding ISM releases to it.
When I start the sprint, a “JIRA Sprint” Release will get created in ISM.
When I go into the Related Releases section of the sprint, I can see the two issues that I put into the sprint in Jira.
Sprints in Jira will now be reflected as releases in ISM. Remember, sprints can only be created from the JIRA side of things. Take a look at the diagram in Figure 13 for a more detailed look at what we just built.
A user will add various issues that already have corresponding releases in ISM to a sprint in JIRA. Only when the sprint is started will the release be created in ISM, and the JIRA Bug and Enhancement releases be linked to it.
Now that you’ve completed parts 1-5 of the series, you have the foundation for integrating Ivanti Service Manager and JIRA Software platforms. If you’re feeling brave, try adding issue field updates or synchronizing comments and journal notes.
Resources
My Jira Automation Rules scan be found here:
Still have questions or want to discuss Jira Software, Ivanti Service Manager, and/or their integration further? Reach out to us at CDA. We’d love to discuss how we can help you with your DevOps and automation needs!
Comments