Service Management plays an integral role in managing, delivering, and auditing changes across the pipeline, as well as tracking incidents that occur as part of the software delivery lifecycle. In this blog series I will showcase four use cases for integrating a FlexDeploy pipeline with ServiceNow.

Another common use case is to is to create a change ticket automatically as part of the pipeline execution. In this use case we will also use the same ticket to govern changes across QA and Production.

Change Management System – ServiceNow

As we saw in the last article in this series, FlexDeploy has integration with ServiceNow right out of the box. To support this use case we will drill down into the advanced configuration.

Default Configuration of ServiceNow in FlexDeploy's Change Management System

To create tickets as part of the pipeline we need to identify the ticket attributes that we want to set for those tickets. By default the ServiceNow CMS has 17 common fields. However, you can add additional fields, including any custom fields you may have configured in ServiceNow.

Add additional fields in the ticket

Notice that the out-of-the-box name, implementation, and other ticket fields are read only. However, you can update the description and add your own custom fields. You just need to ensure the field code matches the attribute name of the JSON returned from the provider’s REST API.

Pipeline Definition

This use case calls for creating a ticket in one stage and then consuming the same ticket in another stage. To share the ticket state across two stages we will make use of Snapshot Variables, which are defined on the pipeline. Here I simply created a snapshot variable to hold the ticket number.

A snapshot variable in FlexDeploy to hold the ticket number

The pipeline defines three stages: Development, QA and Production.

The Development stage does not have any gates and simply deploys the contents of the release snapshot. The QA stage creates a new ServiceNow ticket, and stores the ticket number as a snapshot variable. The Production stage sets the related ticket field from the snapshot variable which was updated after creating the ticket in QA. The External Approval Gate in Production does not create a ticket, rather it uses the ticket number which was set into the stage.

FlexDeploy's three pipeline stages: Development, QA and Production

The QA Approval step creates the ServiceNow ticket. Here I chose to Create Ticket for the stage and initialized two of the ticket values using Groovy expressions.

Creating a ServiceNow ticket in FlexDeploy

The Save Ticket Number gate is a Custom Gate which is used to implement custom logic using a Groovy script. Here I will simply pull the related ticket field (which will be populated when the ticket is created) and store it off in the snapshot variable.

Groovy Script in the Save Ticket Number Gate in FlexDeploy

In the Production stage, the Set Related Ticket gate pulls the value from our snapshot variable and sets it into the related ticket field.

The Set Related Ticket Gate in FlexDeploy

And finally, the CAB Approval gate uses the related ticket field which was populated in the stage such that the user does not have to enter the value.

The CAB Approval Gate in FlexDeploy

In Action!

I have created a snapshot that is now waiting at the QA Approval gate in the QA stage. Here we can see that the related ticket is already set into the stage, which means a new ticket was created.

New Ticket created in FlexDeploy for ServiceNow

I approved the ticket in ServiceNow, and we can see the gate has cleared and the Save Ticket Number step completed. If we look at the snapshot variables for the stage we can see that the variable was updated.

Updated variable in the Snapshot ticket in FlexDeploy.

If we look at the production stage we can see the related ticket was set automatically by the Set Related Ticket script and the gates were cleared automatically.

Related ticket automatically set in the production stage.

Gates automatically cleared in the Production stage.

Summary

This use case highlights how ticket creation can be automated, how a single change ticket can be used to manage more than one stage, and how the ticket can be populated across stages to avoid having to enter the ticket number again manually. What was not shown in this article was that the Approve Checked Script on the CMS instance can be customized to approve based on different criteria in each environment.

Flexibility is king!

Next Post: FlexDeploy Service Management: One Ticket per Release Package

Share this:
Erick Jones

I have been working with Java EE technologies for 25 years, and have applied industry experience implementing IBM and Oracle solutions. Through my architecture and development experience I have implemented several homegrown and third party automation solutions to manage the software delivery lifecycle. At Flexagon I am a DevOps evangelist, with a passion for helping customers deliver software to their customers faster, cheaper, and with higher quality. My primary focus is on FlexDeploy product strategy, and pre-sales and post-sales implementations.

More posts by Erick Jones
    

Leave a Reply

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