Configuring DevOps change request details within the pipeline
Summarize
Summary of Configuring DevOps Change Request Details Within the Pipeline
This guide explains how ServiceNow customers can configure and automate the updating of change request details—such as closure information, change state, and field values—directly from within a DevOps pipeline's change step. It highlights the use of subflows, parameters, and API calls to manage change requests efficiently upon pipeline completion, improving change management integration in DevOps workflows.
Show less
Key Features
- Auto Close Change Feature: Using the
autoCloseChangeparameter in thechangeRequestDetailsobject, customers can automatically update Close code, Close notes, and change state when a pipeline completes. The feature also updates actual start and end dates based on pipeline timings. - Customizable Subflow: The default subflow
sndevops.autoclosechangehandles change closure logic but can be cloned and customized to meet specific organizational requirements. - Pipeline and ServiceNow Field Coordination: Customers can set the
autoCloseChangeflag either in the pipeline or the ServiceNow pipeline record, with the pipeline setting taking precedence. This controls whether the change request is closed or just updated on pipeline completion. - Support and Limitations: Auto close change works only for basic pipelines with a single change request and is unsupported for Jenkins freestyle pipelines, GitLab pipelines, and change requests with change receipt enabled.
- Change Request Field Updates: Customers can specify field values via the DevOps API or pipeline attributes to update change request fields such as
type,cmdbci,assignmentgroup, and others. Risk and impact fields are excluded since they are system-calculated. - Close Code Configuration: The
setCloseCodeparameter controls if Close code and Close notes update when a stage completes. This feature is disabled whenautoCloseChangeis enabled. - API Usage: Use the DevOps
POST /devops/orchestration/changeControlendpoint to create or update change requests with detailed field values.
Practical Application and Considerations
- To enable automatic closure and accurate change request updates, set the
autoCloseChangeparameter totrueorfalseas desired within your pipeline configurations. - Override default start and end date handling by adjusting system properties if you prefer change request times over pipeline times.
- Ensure that all required dependent fields are provided when updating change requests to avoid cancellations of change and step executions.
- During upgrades, reconfigure orchestration tools before enabling the
autoCloseChangeparameter for GitHub and Azure pipelines. - Be mindful of feature incompatibilities, such as unsupported pipeline types and multiple change requests on a single pipeline.
Expected Outcomes
- Streamlined and automated update of change request closure details directly from DevOps pipelines enhances accuracy and reduces manual intervention.
- Consistent synchronization between pipeline execution states and change request statuses ensures compliance and traceability in change management.
- Flexibility to customize closure behavior and field updates allows alignment with unique organizational processes.
Configure how the closure information, change state, and change request fields are updated from within a pipeline in the change step of the pipeline.
The system variable, by default, points to the Default subflow to auto close a change in the base system. The DevOps auto close change on pipeline completion subflow (sn_devops.auto_close_change) determines how the closure information, change state, and change request fields are updated when a pipeline is completed. If you want to specify a custom subflow that must be activated when a pipeline is completed, you can clone this subflow and customize it according to your requirements.
Closure information and change request attributes are contained with the changeRequestDetails object.
Auto close change
If set to true, the Close code and Close notes fields will be updated and the system will try to close the change request when the pipeline is completed.
If set to false, the Close code and Close notes fields will be updated when a pipeline is completed but the change request won’t be closed.
You can also set the Auto close change field value for a pipeline in the ServiceNow application. If you select Update Change Only, the Close code and Close notes fields will be updated when a pipeline is completed, and if you select Update and Close Change, the change request will also be closed along with updating the closure information.
| autoCloseChange flag in change request attributes | Auto Close Change column value (sn_devops_pipeline) | Final state |
|---|---|---|
| True | Update Change Only | Updates change and moves state to close |
| False | Update and Close Change | Only updates the change |
| - | Update Change Only | Only updates the change |
| - | Update and Close Change | Updates change and moves state to close |
- The auto close change feature is only applicable for basic pipelines with a single change created on it. If there are multiple changes, the latest change will be considered for auto close.
- The auto close change feature isn’t supported for Jenkins freestyle pipelines and change requests where the change receipt feature is enabled.
- For an Azure release pipeline, the pipeline completion state is derived by consolidating the state of each stage in the pipeline. If even one stage fails, the pipeline will be considered unsuccessful. If even one stage is partially successful, the pipeline will be considered successful with issues.
Upgrade information
If you’re upgrading, you must re-configure your orchestration tool before setting the autoCloseChange parameter for GitHub and Azure build pipelines.
Set Close Code
Set the setCloseCode: parameter to true/false based on the desired behavior. Default is true.
If set to true, the Close code and Close notes fields are updated as specified in the change step attributes and the change request is moved to post-implement when a stage is completed. You can override this behavior by enabling the Auto close code feature. The setCloseCode feature will get disabled when autoCloseChange is enabled and set to true or false. For more information, see Auto Close Change. Use the autoCloseChange feature for more accurate change request details.
If set to false, when the job or pipeline has completed, the change request isn’t updated and remains in the Implement state.
- Closure Information in the change request isn’t set (Close code and Close notes fields are left empty).
- A link to the step execution is added to the Work notes.
Change request fields
- Use the attributes: parameter to set field values.
- Use the DevOps - POST /devops/orchestration/changeControl endpoint of the DevOps API.
- If a specified field has a dependent field that is required, you must set that attribute as well.
- If the attribute for the dependent required field isn’t set, change request and related step execution are canceled, and work notes are updated.
Field values within the attributes: parameter are key-value pairs. Meaning, the key is the field name within the template and the value is the information to populate in the field.
You can use the changeControl API to specify fields such as type, cmdb_ci, template, assignment_group business_service, standard_change_template, chg_model and create a change request.
When attributes are passed for change, the order of priority is as follows:
- Change request fields or changeControl API.
- Values in the Step record.
- Values provided in the Change Request template.
You can update change fields by passing values from the pipeline for all the supported change fields. The only exception is the list of unsupported fields in the following table.
| Unsupported fields |
|
| Supported fields | All remaining fields in the Change Request [change_request] table. |
Fields such as risk and impact are calculated fields and therefore can't be entered as user inputs. These values are automatically derived based on the change data and the configured risk and impact conditions. To understand how risk and impact are calculated, see Add or modify risk and impact conditions. Once the risk and impact values are calculated, the Risk impact analysis field is automatically populated with the resulting risk and impact information.
Sample JSON payload
{
"callbackURL":"http://192.168.0.4:3000/jenkins/sn-devops/pipeline_839b7605-b98d-4831-bc87-96829de7da37",
"orchestrationTaskURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests#deploy/",
"isMultiBranch":"false",
"orchestrationTaskName":"java_sample_tests#deploy",
"orchestrationTaskDetails":{
"triggerType":"upstream",
"upstreamTaskExecutionURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests/129/execution/node/35/wfapi/describe",
"taskExecutionURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests/129/execution/node/50/wfapi/describe"
},
"changeRequestDetails":{
"setCloseCode":false,
"attributes":{
"sys_created_by":"1832fbe1d701120035ae23c7ce610369",
"sys_updated_by":"56826bf03710200044e0bfc8bcbe5dca",
"requested_by":{
"name":"Abel Tuter"
},
"watch_list":[
{
"name":"Abel Tuter"
},
{
"name":"Aileen Mottern"
},
{
"name":"Alejandra Prenatt"
},
"56826bf03710200044e0bfc8bcbe5dca"
],
"work_notes_list":[
"56826bf03710200044e0bfc8bcbe5dca",
"46c6f9efa9fe198101ddf5eed9adf6e7",
"d8f57f140b20220050192f15d6673a98"
],
"assigned_to":"1832fbe1d701120035ae23c7ce610369",
"category":"Service",
"sys_created_on":"2021-02-09 18:58:41",
"priority":"2",
}
}
}