{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":32103,"path":"it-service-management/devops-change-velocity/dev-ops-change-acceleration.md","title":"Accelerating your DevOps change process","bundle":null,"doc_type":null,"release":"australia","body":"\n# Accelerating your DevOps change process\n\nEnable 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.\n\n**Note:** ServiceNow [Change Management](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/c_ITILChangeManagement.md) must be installed for change acceleration.\n\nEnable and set up change control when you model your pipeline in DevOps:\n\n- [Model an Azure pipeline in DevOps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/model-azure-pipeline-dev-ops.md)\n- [Model a GitLab basic CI pipeline in DevOps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/model-gitlab-pipeline-dev-ops.md)\n- [Model a Jenkins pipeline in DevOps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/model-jenkins-pipeline-dev-ops.md)\n\nYou can view details for active change requests by navigating to **DevOps** > **Orchestrate** > **Pipeline Change Requests**.\n\n## Change control process\n\nWhen 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.\n\nPipeline steps can be configured to enable change receipts, which don't pause the pipeline. Change requests created with change receipts enabled include all pipeline data, but don't 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.\n\nIf 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-administration.md).\n\nOnce 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-change-acceleration.md).\n\nIf 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:\n\nFor Jenkins: `[ServiceNow DevOps] Job was not approved for execution`\n\nFor GitHub: `Error: **** Change has been created but the change is either rejected or cancelled`\n\nFor ADO: `\"changeState\":\"Closed\"`\n\n## Automatic approval of change requests using flows and policies\n\nYou 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.\n\n## Flows\n\nA 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/application-development/flow-designer.md).\n\nYou 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\\).\n\nBy default, the flows are configured to update the state of the step execution based on the change request state, and any additional default behavior. Based on the step execution state, a callback is made to the pipeline:\n\n- 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.\n- 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.\n- 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.\n\nIf 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.\n\n\n
\n\nDevOps flow\n\n\n\nDefault behavior\n\n
\n\nDevOps Change Request Manual Approval Flow\n\n\n\nThis flow is activated by default. With this flow, DevOps change requests must go through a manual approval process, where the flow waits for the change request to reach an eligible state \\(rejected, implemented, or specific implementation state\\). When reached, this flow will update the state of the step execution based on the state of the change request.\n\n If the change request is type-based, the flow will wait for the change to get rejected, implemented, or canceled. If the change request is model-based, the flow will wait for the change to get rejected, get canceled, or reach one of the implementation states defined in the model or the implement state specified in the DevOps property. This flow won’t trigger for DevOps change requests whose model is a base system DevOps change model \\(DevOps or DevOps simplified\\) to avoid conflicts and errors. \\[Omitted image \"change-manual-flow.png\"\\] Alt text: DevOps Change Request Manual Approval Flow\n\n You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated.\n\n
\n\nDevOps Change Request Minimal Automation Approval Flow\n\n\n\nThis flow gathers DevOps data and runs the DevOps Change Request Minimal Automation Policy, which determines if the change should be auto-rejected, auto-approved, or sent for manual approval. This flow is triggered for DevOps change requests whose type or model is set to normal.\n\n Activate this flow if you want to automate change request approvals, but start minimally. \\[Omitted image \"change-minimal-automation-flow.png\"\\] Alt text: DevOps Change Request Minimal Automation Approval flow\n\n You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated.\n\n You can also add the DevOps - Update Minimal Automation Policy Decision Reason action to this flow to update the policy decisions to the step execution change comment and the change request worknotes to know the reasons for the decision. You can add this action inside every decision block and specify the required input. \\[Omitted image \"action-minimal-automation-policy.png\"\\] Alt text: Update minimal automation policy decision action\n\n
\n\nDevOps Change Request Advanced Automation Approval Flow\n\n\n\nThis flow gathers DevOps data and runs the DevOps Change Request Advanced Automation Policy, which determines if the change should be auto-rejected, auto-approved, or sent for manual approval. This flow is triggered for DevOps change requests whose type or model is set to normal.\n\n If the DevOps change request is approved, the flow will update the change request to the scheduled state, and the planned start date will be used to set the change request start date. On the change request start date, the flow will update the change request state to implement. After that the pipeline will be resumed. Activate this flow if you want to automate change request approvals with a robust change policy. \\[Omitted image \"change-flow-advanced.png\"\\] Alt text: DevOps Change Request Advanced Automation Approval Flow\n\n You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated.\n\n
\n\nDevOps  Demo  Change Automation flow \n\n\n\nWhen demo data is installed, the  DevOps  Demo  Change Automation flow  is available where  normal type of change request or normal model change request can be auto-approved based on the decision policies.  As a part of demo data, the decision policies available are: - DevOps Low Risk Auto Approval policy, where the failed test count is zero  .\n- DevOps High risk manual approval policy, where the failed test count is greater than zero .\n\n\\[Omitted image \"dev-ops-demo-chg-automation-flow.png\"\\] Alt text: DevOps Demo Change Automation flow You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated.\n\n
To read guidelines on how to use flows, subflows, and actions more effectively, see [General guidelines for Workflow Studio flows, subflows, and actions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/build-workflows/design-considerations-consolidated.md).\n\n## Change approval policies\n\nA change approval policy is a course of action that can be applied to a change request. It consists of the following:\n\n- Policy input: Variable sources evaluated within a condition.\n- Decisions: Determines whether the change approval definition must be applied based on conditions.\n- Approval definitions: Defines the type of approval that can be applied.\n\nThe DevOps Change Request Minimal Automation Policy and DevOps Change Request Advanced Automation Policy are available by default. The three normal change policies available are:\n\n- DevOps Model Change Policy\n- DevOps Change Request Minimal Automation Policy\n- DevOps Change Request Advanced Automation Policy\n\nFor more information on change approval policies, see [Change approval policies](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/change-approval-policy.md).\n\nThe 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.\n\nThe DevOps Change Request Minimal Automation Policy has the following conditions and criteria by default: \\[Omitted image \"change-policy-minimal.png\"\\] Alt text: Change Request Minimal Automation Policy conditions\n\nThe DevOps Change Request Advanced Automation Policy has the following conditions and criteria by default:\\[Omitted image \"change-policy-advanced.png\"\\] Alt text: Change Request Advanced Automation Policy conditions\n\nThe three outcomes for the DevOps Change Request Minimal Automation and DevOps Change Request Advanced Automation policies \\(depending on the conditions that you specify\\) are:\n\n- Auto approval: If the conditions specified in the policy are met, the change request is automatically approved.\n- Auto reject: If one or more of the conditions specified in the policy are not met, the change request is automatically rejected.\n- 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.\n\nYou 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/use-apply-change-approval-policy-flow-activity.md).\n\n## Change approval work notes\n\nWhen 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:\n\n- Change Approval Policy not found. Change Request has been rejected \\(%s\\).\n- %s is inactive. Change Request has been rejected \\(%s\\).\n- No Decisions matched. %s has been skipped \\(%s\\).\n- No approvals were generated from matched Decisions. %s has been skipped \\(%s\\).\n- Change Request has been rejected by %s \\(%s\\).\n- Change Request has been approved by %s \\(%s\\).\n\nThe work notes are updated based on a logic which uses the combination of one of the hard-coded messages + the policy name + action label used in the flow associated with the change request. In this combination, you can change only the value of policy name and the action label but not the hard-coded message. For example,\n\n```\nif (APPROVED.equals(state))\n38 message = String.format(APPROVED_MSG, policyName, actionLabel);\n```\n\n## Default Change Handler subflow\n\nUse the Default Change Handler subflow to populate these change request fields with default values.\n\n- Requested by\n- Justification\n- Implementation Plan\n- Backout plan\n- Test Plan\n- Short Description\n- Description\n- Start Date\n- End Date\n- Risk Impact Analysis\n\nThe Default Change Handler subflow overrides the field values that were populated using a template while creating the change request record.\n\nIf desired, you can write a custom subflow in place of this flow by modifying the **\\[sn\\_devops.change\\_request\\_handler\\_subflow\\]** [DevOps property](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-administration.md).\n\n## Custom change request templates\n\nWhen you enable change control in the ServiceNow DevOps step , you can select a custom template to populate fields automatically while creating the change request. The change request **Category** field is automatically set to DevOps.\n\n**Note:** Do not configure the **Category** and **changeType** fields from the custom template.\n\nThe type of change request corresponds to the change request table in global scope.\n\n## Automatic change request related lists\n\nFor a change request automatically created by DevOps, the **Category** field is automatically set to DevOps, and these related lists are added:\n\n- **Commits**\n\n Commits associated with the change request.\n\n- **Work Items**\n\n Work items associated with the change request.\n\n- **Artifact Versions**\n\n List of artifact versions associated to the package linked to pipeline execution for packages created before the change request is approved.\n\n If no package is linked to the pipeline execution, then the list is empty.\n\n- **Test Summaries \\(replaces Test Results related list\\)**\n\n List of test summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.\n\n See [Test Results](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-change-acceleration.md) for more details.\n\n- **Software Quality Summary**\n\n List of software quality summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.\n\n- **Security Summaries**\n\n List of security summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.\n\n **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.\n\n\n\\[Omitted image \"dev-ops-change-rel-lists.png\"\\] Alt text: DevOps Change Related Lists\n\n**Note:** Implementation details from the orchestration tool are automatically added to the **Work notes** field on the change request form. Detail added to the work notes is limited to 5 KB of the task execution log for the step.\n\n## Custom change request process\n\nThese [DevOps change properties](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-administration.md) are available to customize your change request flow.\n\n- DevOps change request implement state\n- DevOps change request post implement state\n- DevOps change request cancel state\n- DevOps change request approval text\n\nTo customize your change request flow, you must first create a **System Definition** > **Choice List**. For example, `DevOps_Implement (value - 10)`.\n\nThen, add the choice list to **System Definition** > **Script Include** > **ChangeRequestStateHandlerSNC**.\n\nOnce you have created the choice list and added it to the script include, you can update [DevOps change properties](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-administration.md) with the new choice list values. For example, **DevOps change request implement state** `-10`.\n\n## DevOps Risk Condition\n\nYou can use the DevOps risk and impact calculation based on committer risk score.\n\nThis condition is inactive by default.\n\n## Test Results related list\n\nLists 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.\n\nScenarios:\n\n- **A package is created in the pipeline, but no artifact versions are registered.**\n - If the change request is created in the package creation stage:\n\n No test results are displayed because a package is not yet linked to the pipeline execution.\n\n - If the change request is created in a stage after the package creation stage:\n\n Build test summaries include those associated with stages after the package creation stage, up to the change-controlled stage.\n\n- **Artifact versions are registered, but no package is created.**\n - If the change request is created in the artifact version stage:\n\n No test results will be displayed, because no tests are associated until the task execution is completed.\n\n - If the change request is created in a stage after the artifact version stage:\n\n Build test summaries include those in the artifact version stage, as well as the stages afterward, up to the change-controlled stage.\n\n- **Both artifact versions and package are created in the pipeline.**\n - If the change request is part of the stage after artifact version and package creation stages:\n\n Build test summaries include those associated with the package creation stage, as well as the stages afterward, up to the change-controlled stage.\n\n - If the change request is part of the package creation stage, and artifact versions are created as part of an earlier stage;\n\n - or the change request is created in a stage \\(not package creation\\) after the artifact version stage, but before package creation stage;\n - or the change request is part of the package creation stage and artifact versions are created as part of an earlier stage:\n Build test summaries include those associated with the artifact version stage, as well as stages afterward, up to the change-controlled stage.\n\n\n## Pipeline executions view\n\nYou can view pipeline activity by navigating to **DevOps** > **Orchestrate** > **Pipeline Executions**.\n\n\\[Omitted image \"dev-ops-pipeline-executions.png\"\\] Alt text: DevOps pipeline execution\n\n- **[Customizing DevOps flows](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/using-dev-ops-model-change-flow.md)** \nCustomize or recreate the DevOps Change Request Manual Approval, DevOps Change Request Minimal Automation Approval, and DevOps Change Request Advanced Automation Approval flows based on your requirements using a flow or a script.\n- **[Automate DevOps change request creation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/automate-devops-change-request.md)** \nModify your pipeline to automatically create a DevOps change request.\n- **[Create a DevOps Change request and associate existing DevOps data — Workspace](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/devops-wkspc-chg-create-manual.md)** \nCreate a DevOps change request and associate existing DevOps data through the Workspace UI.\n- **[Create a DevOps change request and associate existing DevOps data — Classic](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/create-devops-change-request-manual.md)** \nCreate a DevOps change request and associate existing DevOps data through the Classic UI.\n- **[DevOps change request without mandating category as DevOps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/create-devops-change-any-category.md)** \nEnable categorizing DevOps change request from DevOps properties. Change requests that are created as part of pipeline execution steps can be created with a category other than DevOps.\n- **[Change request creation with DevOps data retrieval errors](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/change-request-creation-with-devops-data-retrieval-errors.md)** \nCreate change requests even with errors in DevOps data retrieval.\n- **[Artifacts and packages](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/using-dev-ops-release-change.md)** \nArtifacts and packages enable DevOps Change Velocity to track development and testing activities across a wide range of deployment and release models. This feature ensures that pipeline activity stored in the DevOps data model can be retrieved and applied when artifacts are created and released at different times or in different pipelines.\n- **[DevOps Pipeline UI](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-pipeline-ui.md)** \nUse the Pipeline UI to visualize interactions and results across a pipeline execution. This graphical view shows pipeline step progression and other details for each pipeline.\n- **[Configuring DevOps change request details within the pipeline](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/dev-ops-config-change-details.md)** \nConfigure how the closure information, change state, and change request fields are updated from within a pipeline in the change step of the pipeline.\n- **[DevOps change models](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/devops-change-multimodel.md)** \nDevOps Change Velocity enables you to use fit-for-purpose change models that allow better flexibility in defining change models or processes to reflect modern development practices.\n- **[Retrieve change request data using DevOpsChangeRelationshipHelper script](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/retrieve-change-request-data-using-devopschangerelationshiphelper-script.md)** \nRetrieve data associated with a change request based on the specified relation type using the DevOpsChangeRelationshipHelper script include.\n- **[Manage Pull Requests \\(PR\\) or Merge Requests](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/manage-pull-request-pipelines.md)** \nManage Jenkins, GitHub Actions, and Azure DevOps \\(ADO\\) pipeline’s pull requests for GitHub, Bitbucket, and ADO coding sources from ServiceNow DevOps. You can enable the change approval process on your pull request to control pull request merge approvals from ServiceNow DevOps and monitor pull request details associated with the change request.\n- **[DevOps change request attributes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/apis-for-change-actions-in-devops.md)** \nAdd or update DevOps change request attributes using the changeInfo REST API, the Default Change Handler subflow, by passing attributes through the pipeline, Update function, or automated flows.\n- **[Import based evidence collection](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/import-based-evidence-collection-for-orchestration-capability.md)** \nReduce instance overhead by skipping step-level pipeline processing for accelerated change management and evidence collection for GitHub Actions, Azure DevOps \\(ADO\\), Jenkins and GitLab orchestration tools.\n\n**Parent Topic:**[DevOps Change Velocity](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/devops-change-velocity/devops-landing-page-new.md)\n\n"}}