ServiceNow - Azure DevOps Integration

The IT industry needs optimal efficiency in its enterprise, which is not an easy task. Traditional practices are still in use but are not beneficial as they can slow down the process considerably. So, here comes ServiceNow, which has become a complete packed solution for IT Industries.

ServiceNow is software based on the cloud, providing IT services for automating business tasks and their management. It uses Machine Learning technology to automate processes and create workflows.

Azure DevOps supports a collaborative culture and set of processes that bring together developers, project managers, and contributors to develop software. It allows organizations to create and improve products at a faster pace than they can with traditional software development approaches.

In this article, we will discuss, how to use ServiceNow effectively by integrating it with Azure DevOps.

Prerequisites for Integration

An Azure DevOps organization. Create an organization, if you don’t have one already.
A non-developer instance of ServiceNow.

Configure the ServiceNow instance

Install the Azure Pipelines extension on your ServiceNow instance. You’ll need Hi credentials to complete the installation. See Buying Overview for more details on installing apps from the ServiceNow store.
Create a new user in ServiceNow and grant it the following role: x_mioms_azpipeline.pipelinesExecution.

Integrating SNOW in Azure DevOps Organisation

Install the ServiceNow Change Management extension on your Azure DevOps organization.

Create a new ServiceNow service connection in your Azure DevOps project as follows. Alternatively, you can also use OAuth2 authentication.

Configure the Release Pipeline

Navigate to your release pipeline, and then select the Pre-deployment conditions icon. Select Gates and the ServiceNow Change Management pre-deployment gate.

Select the service connection you created earlier and fill out the required fields as follows:

ServiceNow connection: Connection to the ServiceNow instance used for change management.
Short description: A summary of the change.
Description: A detailed description of the change.
Category: The category of the change. Example: Hardware, Network, Software.
Priority: Priority of the change.
Risk: The risk level for the change.
Impact: The effect that the change has on business.
Configuration Item: Configuration item (CI) that the change applies to.
Assignment group: The group that the change is assigned to.
Schedule of change request: Schedule of the change as honored by the ServiceNow workflow. Date and time should be in UTC and format should be yyyy-MM-ddTHH:mm:ssZ. Example: 2018-01-31T07:56:59Z.
Additional change request parameters: Name must be field name (not label) prefixed with ‘u_’. Example: u_backout_plan. Value must be a valid value in ServiceNow. Invalid entries are ignored.
Desired state of change request: The gate would succeed and the pipeline continues when the change request status is the same as the provided value.
Advanced: Specifies an expression that controls when this gate should succeed. The change request is defined as root[‘result’] in the response from ServiceNow.
Output Variables : You must specify a reference name to be able to use output variables in your deployment workflow. Gate variables can be accessed by using “PREDEPLOYGATE” as a “prefix” in an agentless job. For example when the reference name is set to ‘gate1’, the change number can be obtained as follows: $(PREDEPLOYGATE.gate1.CHANGE_REQUEST_NUMBER).
CHANGE_REQUEST_NUMBER : Number of the change request.
CHANGE_SYSTEM_ID : System Id of the change request.
ServiceNow connection: Connection to the ServiceNow instance used for change management.
Change request number: Number of the change request to update.
Updated status of change request : Status to set for the change request. This input is available if Update status is selected.
Close code and Close notes: Return status.

Note:- The Update ServiceNow Change Request task will fail if none of the change request fields are updated during execution. ServiceNow ignores invalid fields and values passed to the task.

Create a Release Pipeline

Select Create release to start a new release pipeline. Your pipeline should create a new change request in ServiceNow as part of the pre-deployment conditions you created earlier.

The pipeline will wait for all the gates to succeed within the same sample interval. To check the change number, select the status icon to view your pipeline logs.

The change request will be queued in ServiceNow and can be viewed by the change owner.

The release pipeline that triggered the new change request can be found under the Azure DevOps Pipeline metadata section.

When the change is ready for implementation (moved to Implement state), the pipeline will resume execution and the gate status should return to succeeded.

The change request will be closed automatically after deployment.

That’s all. The integration is done now.

Conclusion

There is quite a long list of potential use cases for integrating ServiceNow and Azure DevOps.

To auto-create changes from Azure Pipelines, and automatically deploy them once a change is (auto) approved, we have integrated ADO Pipelines with SN Change Management. In this way, we can easily automate change management.

Reference

Blog Pundits: Mehul Sharma and Sandeep Rawat

Opstree is an End to End DevOps solution provider.

Connect with Us