UrbanCode Deploy & ServiceNow integration Part 1

In this post I’m going to show you how to integrate UrbanCode Deploy and the cloud-based IT Service Management (ITSM) platform ServiceNow.

We can orchestrate deployments from ServiceNow by invoking outbound UCD REST services, as well as configure UCD to call ServiceNow to create, update changes, incidents, tasks, or other ServiceNow table records.

For my purpose, I’ve used the ServiceNow Developer Program who provides developers with resources to learn, build and deploy applications on the ServiceNow platform.

I’ve used “New York” ServiceNow version. Things can change if you use a different version.

Additionally, I’ve installed the ServiceNow plugin on UCD which allows to easily perform CRUD (create, read, update and delete) operations on records with convenient steps such as check and query records.

In this first scenario I want to deploy my application and, at the same time, create a Standard Change Request on ServiceNow, but only for a specific environment (eg. UAT).

A Standard Change is a pre-approved, low risk change with a proven history of success. Standard changes are implemented often with repeatable steps and are often areas where automation can be implemented to help speed up the process and increase efficiency.

Here below you can see the application process. The flow diagram is made of several steps.

– Acquire lock.
– Create the Change Request (CHG).
– Update some fileds on the CHG.
– Deploy a war file.
– Add an attachment to the CHG.
– Close complete the CHG in case of successful deployment.
– Close the CHG incomplete in case of deployment failure.
– Release lock.

To create the Standard CHG only on UAT environment we use the “Precondition” feature of UCD.

UCD and ServiceNow integration is possible using the Automation Plugin steps, but also using more flexible REST APIs commands via Shell steps.
ServiceNow Change Management API, for example, provides REST APIs that enable third-party application integration with the ServiceNow Change Management process (click here for more information).

Let’s take a closer look to the Component Process “Create ServiceNow CHG”.

In the below process I’ve used a Shell step with REST API endpoint to create the standard change.

curl -s "${p:ServiceNowUrl}/api/sn_chg_rest/change/standard/${p:ServiceNowTemplate}" \
--request POST \
--header "Accept:application/json" \
--user '${p:ServiceNowUser}':'${p:ServiceNowPassword}'

I’ve used some UCD properties:

– ServiceNowUrl
– ServiceNowTemplate: The SysId of the Standard Change Template.
– ServiceNowUser
– ServiceNowPassword

After creating the change, I’ve used UCD post script feature and added some more steps to retrieve below info:

– CR_TEMP: A temporary property to store the change number.
– SYS_ID_TEMP: A temporary property to store the change sysid.

Once created the change and stored properties I’ve used a ServiceNow plugin step to update some change request fields:

Change Request fields to update are “Service” and “Short Description” as showed below:

After updating the CHG I’m going to deploy a war file and then upload the artifact to ServiceNow CHG.

Finally the CHG is closed complete in case of successful deployment or closed canceled in case of deployment failure.

To upload artifact to the change request I’ve used another REST Api endpoint (click here for more info):

curl -s "${p:ServiceNowUrl}/api/now/attachment/file?table_name=change_request&table_sys_id=${p:SYS_ID_TEMP}&file_name=JPetStore.war" \
--request POST \
--header "Accept:application/json" \
--user '${p:ServiceNowUser}':'${p:ServiceNowPassword}' \
--header "Content-Type: application/java-archive" \
--data-binary "@./JPetStore.war"
Please note that in this case the endpoint needs the sys_id of the change request and not the change number.

Finally it’s time to close the change, completed or canceled, based on the success/failure of the deployment.

Let’s have a closer look to the steps used. In both cases I’ve used the “Update Record” ServiceNow plugin step.

Closed Complete:

Closed Canceled:

Please note the “state” and the “close_code” used above.

More info on change request states are available here .

Now it’s time to see how the full process works:

This is the end of Part 1. In the next post I’ll show you how orchestrate deployments from ServiceNow by invoking outbound UCD REST services.

Have a nice day!

2C DevOps Ltd. Director, UrbanCode Deploy expert. Drop email to info@2cdevops.co.uk for info and consultancy advice.