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.

Starting with version 1.20, pipeline steps can be configured to create change receipts, which do not pause the pipeline. Change receipts include all pipeline data, but do not require approval to proceed in the pipeline.

Change requests can be approved automatically by configuring conditions in a change approval policy. The DevOps change approval policy (DevOps Change Policy) and workflow (Change Request - DevOps) are provided with the DevOps application.

The difference in the DevOps workflow (Change Request - DevOps) from the Normal workflow (Change Request - Normal) is that the change approval policy in the DevOps workflow is the DevOps Change Policy instead of the Normal Change Policy and, therefore, does not use Technical approvals nor Risk approvals activities that are part of the Normal workflow.

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 Closed with Close code as Successful on a successful job run, or Unsuccessful on error in the job run.

If a change request is not approved and moved into canceled state or closed state, the associated Jenkins job is marked as failed and a console message is shown:

[ServiceNow DevOps] Job was not approved for execution

Automatic approval of change requests using Change Policy workflows

You can enable automatic approval of DevOps changes using the Change Approval Policy workflow and the DevOps Change Policy workflow.

Custom change request templates

Starting with version 1.14, when you configure change acceleration, you can select a custom template to populate fields automatically when creating the change request. In the ServiceNow DevOps step, set the change type as standard, normal, or emergency and select the custom template for the change.

The type of change request corresponds to the change request table in global scope.

DevOps Model Change Request flow

Starting with version 1.14, customize the DevOps Model Change Request flow using a flow or a script.

Once the change request is approved, rejected, or canceled, the state of the step execution can be updated by calling Flow Designer action Update the state of step execution table even before implementing the change request. If a change request is not approved, and moved into  canceled or rejected state, the associated job is marked as  canceled or failed and a console message is shown.

Flow Designer action Update the state of step execution table serves as a trigger for Change Control Callback flow, which is used to notify the change decision to the orchestration tool. Hence, calling the Flow Designer action Update the state of step execution table is mandatory. 

Automatic change request related lists

Custom change request process

These DevOps change properties are available to customize your change request flow.

To customize your change request flow, you must first create a System Definition > Choice List. For example, DevOps_Implement (value - 10).

Then, add the choice list to System Definition > Script Include > ChangeRequestStateHandlerSNC.

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.

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.

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.

Pipeline executions view

You can view pipeline activity by navigating to DevOps > Orchestrate > Pipeline Executions.