DevOps Change Velocity - GitHub Deployment Gates for ServiceNow DevOps Change

Nived K2
Tera Contributor

Hi Team,

 

I am using ServiceNow DevOps Change Automation custom action on the GitHub workflow to create a change request in ServiceNow. It is creating a change request in the ServiceNow instance to pause and resume the workflow run.

But when I use GitHub Deployment Gate capability to decide on whether a new deployment should proceed or halt, the workflow run is not creating a change request in ServiceNow.

 

Any suggestion ?

 

Thank you,

Nived K 

 

1 REPLY 1

charliek95
Tera Contributor

After some head-scratching, I think I've finally figured out how this works! 

 

If we use the example from the documentation: https://www.servicenow.com/docs/bundle/yokohama-it-service-management/page/product/enterprise-dev-op...

 

When you add to the raise change payload:

'{"environment":"deployment_gate","jobName":"Deploy"}'

It changes the behavior of how & when the changed is raised. Now, the raise change stage will pass immediately with changeControl: False. The change request payload is stored in a row sn_devops_callback with the state "Ready to process"

 

The pipeline then continues until it reaches the deployment gate (stage deploy in the example), at this point the webhook configured on the GitHub App - which is subscribed to "Deployment Protection Rules" fires off the deployment_protection_rule.requested event to ServiceNow. Which finds the "Ready to process"  in sn_devops_callback previously, and raises the Change Request against the deployment gate step instead, the record in sn_devops_callback then goes into Successful state. A new callback row is added again to sn_devops_callback linking the github api url to trigger deployment with the change request.

 

When that goes into approved/rejected state - it fires the API call to GitHub to trigger the deployment.

 

It was very confusing wrapping my head around it to begin with, but it makes sense - you want the change to be linked to the deployment gate step in the pipeline, not the raise change step when using deployment gates.

 

Hope this helps speed up someone's troubleshooting in the future!