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.
- FlexDeploy Service Management: Manual Ticket Entry
- FlexDeploy Service Management: Automated Ticket Creation for QA and Production
- FlexDeploy Service Management: One Ticket per Release Package
- FlexDeploy Service Management: Create Incident on Workflow Failure
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.
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.
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.
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.
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.
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.
In the Production stage, the Set Related Ticket gate pulls the value from our snapshot variable and sets it into the related ticket field.
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.
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.
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.
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.
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
