Accelerating your DevOps change process
-
- UpdatedJan 30, 2025
- 14 minutes to read
- Yokohama
- DevOps
Enable the change acceleration feature of DevOps Change Velocity for automatic change request creation in your pipeline, and use change approval flows and policies to automate approval under certain conditions.
You can view details for active change requests by navigating to
.Change control process
When change control is enabled for a job in your DevOps development pipeline, a change request is automatically created and set to Assess state to request approval for the execution of the current stage or job if an assignment group is added for the change request. Change requests can be approved automatically by configuring conditions in a change approval policy.
Pipeline steps can be configured to enable change receipts, which do not pause the pipeline. Change requests created with change receipts enabled include all pipeline data, but do not require approval to proceed in the pipeline and the change request will be in post implement states. For change requests created without enabling change receipt, the pipeline will be paused until the change request is approved, and upon approval, the pipeline will be resumed.
If you want to stop the automatic transition of the change request states even when change receipt is turned on, you must disable the sn_devops.enable_change_receipt_state_transition property. For more information, see DevOps Change Velocity properties.
Once approved, either automatically or manually, change requests move to Implement state and the job is run. Once the job is run, the change request is moved to the closed state with Close code as successful on a successful job run or Unsuccessful on error in the job run. For information on customizing your change request states, see Custom change request process.
If a change request is not approved and moved to the canceled or closed state, the associated Jenkins, GitHub, or ADO job is marked as failed and a console message is shown:
For Jenkins: [ServiceNow DevOps] Job was not approved for execution
For GitHub: Error: **** Change has been created but the change is either rejected or cancelled
For ADO: "changeState":"Closed"
Automatic approval of change requests using flows and policies
You can automate the change approval process for all your DevOps change requests. DevOps Change Velocity uses flows and DevOps data (such as work items, commits, code coverage, code security, risk, and test results) to update the state of a change request and automatically approve it based on change approval policies. Three flows are available in the base system that you can clone, customize, and activate (in Flow Designer). By default, the DevOps Change Request Manual Approval Flow is activated. DevOps flows are applicable to only automatically created change requests or change requests that have change receipt turned off.
Flows
A flow is an automated process consisting of a trigger (which specifies when to run the flow) and a sequence of reusable actions (where the actions perform a sequence of operations on your data). Flows are built in Flow Designer, a ServiceNow AI Platform feature that enables process automation. For more information, see Flow Designer.
You can use one of the DevOps flows available in the base system as a template; clone the flow and customize it to your business requirements. Ensure that only one DevOps flow is in the active state at any time to avoid conflicts and errors. A DevOps flow is applicable to change requests that have the DevOps category or if the devops_change property is set to true. (An automatically created DevOps change request sets the category to DevOps by default).
- If the DevOps change request is approved, the flow will update the step execution state to approved, and the change request state is updated to implement. After that the pipeline will be resumed.
- If the DevOps change request is rejected, the flow will update the step execution state to rejected, and the change request state is updated to new. After that the pipeline will be terminated.
- If the DevOps change request is canceled, the flow will update the step execution state to canceled by user, and the change request is updated to canceled. After that the pipeline will be canceled.
If a business rule or data policy causes an error while updating a change in the DevOps Change Request Manual Approval Flow, DevOps Change Request Minimal Automation Approval Flow, or DevOps Change Request Advanced Automation Approval Flow, the corresponding error will be displayed in the worknotes of the change request and logged in the console logs of the pipeline tool.
To read guidelines on how to use flows, subflows, and actions more effectively, see General guidelines for Workflow Studio flows, subflows, and actions.
Change approval policies
- Policy input: Variable sources evaluated within a condition.
- Decisions: Determines whether the change approval definition must be applied based on conditions.
- Approval definitions: Defines the type of approval that can be applied.
- DevOps Model Change Policy
- DevOps Change Request Minimal Automation Policy
- DevOps Change Request Advanced Automation Policy
For more information on change approval policies, see Change approval policies.
The DevOps automated approval flows use change approval policies and DevOps data (such as work items, commits, pull requests, test summaries, security summaries, and quality summaries) to automatically update the change record state and step execution state to approved, rejected, or canceled. You can view and edit these policies based on your business requirements, or create your own in the decision table. See the following decision tables.
The DevOps Change Request Minimal Automation Policy has the following conditions and criteria by default:
The DevOps Change Request Advanced Automation Policy has the following conditions and criteria by default:
- Auto approval: If the conditions specified in the policy are met, the change request is automatically approved.
- Auto reject: If one or more of the conditions specified in the policy are not met, the change request is automatically rejected.
- Manual approval: If one or more conditions need manual approval by a user or group, that is specified in the policy. Notifications are sent by the policy to the relevant users or groups to expedite the manual approval and progress the change request.
You can apply your change approval policy in the Change Management Workflow Studio action to control the approval process for a change request. For more information, Use the Apply Change Approval Policy flow action.
Change approval work notes
When a change request is updated based on a flow and change approval policy, the work notes associated with the change request are updated to one of the following hard-coded messages:
- Change Approval Policy not found. Change Request has been rejected (%s).
- %s is inactive. Change Request has been rejected (%s).
- No Decisions matched. %s has been skipped (%s).
- No approvals were generated from matched Decisions. %s has been skipped (%s).
- Change Request has been rejected by %s (%s).
- Change Request has been approved by %s (%s).
Default Change Handler subflow
- Requested by
- Justification
- Implementation Plan
- Backout plan
- Test Plan
- Short Description
- Description
- Start Date
- End Date
- Risk Impact Analysis
The Default Change Handler subflow overrides the field values that were populated using a template while creating the change request record.
If desired, you can write a custom subflow in place of this flow by modifying the [sn_devops.change_request_handler_subflow] DevOps property.
Custom change request templates
The type of change request corresponds to the change request table in global scope.
Automatic change request related lists
- Commits
- Commits associated with the change request.
- Work Items
- Work items associated with the change request.
- Artifact Versions
List of artifact versions associated to the package linked to pipeline execution for packages created before the change request is approved.
If no package is linked to the pipeline execution, then the list is empty.
- Test Summaries (replaces Test Results related list)
List of test summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.
See Test Results for more details.
- Software Quality Summary
- List of software quality summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.
- Security Summaries
- List of security summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.Note: Security scan results on the change record associated to a pipeline execution with a linked package are also displayed in the Security Summaries tab.
Custom change request process
These DevOps change properties are available to customize your change request flow.
- DevOps change request implement state
- DevOps change request post implement state
- DevOps change request cancel state
- DevOps change request approval text
To customize your change request flow, you must first create a
. For example, DevOps_Implement (value - 10).Then, add the choice list to
.Once you have created the choice list and added it to the script include, you can update DevOps change properties with the new choice list values. For example, DevOps change request implement state -10.
DevOps Risk Condition
You can use the DevOps risk and impact calculation based on committer risk score.
This condition is inactive by default.
Test Results related list
Lists the tests that were run in a pipeline after a package was created. If no package was created, then the list includes the tests that were run after an artifact version was created.
Scenarios:
- A package is created in the pipeline, but no artifact versions are registered.
- If the change request is created in the package creation stage:
No test results are displayed because a package is not yet linked to the pipeline execution.
- If the change request is created in a stage after the package creation
stage:
Build test summaries include those associated with stages after the package creation stage, up to the change-controlled stage.
- If the change request is created in the package creation stage:
- Artifact versions are registered, but no package is created.
- If the change request is created in the artifact version stage:
No test results will be displayed, because no tests are associated until the task execution is completed.
- If the change request is created in a stage after the artifact version
stage:
Build test summaries include those in the artifact version stage, as well as the stages afterward, up to the change-controlled stage.
- If the change request is created in the artifact version stage:
- Both artifact versions and package are created in the pipeline.
- If the change request is part of the stage after artifact version and package
creation stages:
Build test summaries include those associated with the package creation stage, as well as the stages afterward, up to the change-controlled stage.
- If the change request is part of the package creation stage, and artifact versions
are created as part of an earlier stage;
- or the change request is created in a stage (not package creation) after the artifact version stage, but before package creation stage;
- or the change request is part of the package creation stage and artifact versions are created as part of an earlier stage:
Build test summaries include those associated with the artifact version stage, as well as stages afterward, up to the change-controlled stage.
- If the change request is part of the stage after artifact version and package
creation stages:
Pipeline executions view
You can view pipeline activity by navigating to
.On this page
- Change control process
- Automatic approval of change requests using flows and policies
- Flows
- Change approval policies
- Change approval work notes
- Default Change Handler subflow
- Custom change request templates
- Automatic change request related lists
- Custom change request process
- DevOps Risk Condition
- Test Results related list
- Pipeline executions view