DevOps model change - Product Documentation: Washington DC

DevOps model change

DevOps > DevOps Change Velocity >

DevOps model change

DevOps 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.

Overview Important: For DevOps change requests, use the Change Management - Change Models feature, which provides greater flexibility to enable the change process flow in a way that is optimized for specific use cases. For more information, see Change models . The legacy Change Management - State Model is also supported. For more information, see State model and transitions .

Important: The DevOps change model is not supported for Argo CD and Split tool change requests.

Use fit-for-purpose change models with a suite of succinct flows and flow actions built in Flow Designer for specific use cases. Instead of using the legacy ITIL-based change processes that are predefined in change workflows (Normal, Standard, and Emergency), you can selectively transition to a wide range of models that are optimized for specific use cases. Change models can be created with states and rules that determine the transitions between the states. For information on change models, see Change models .

You can use any of the base system change models including the DevOps change model. To create a change request based on models, you can either configure the Model field in the Step form in ServiceNow, or pass the model sys_id or name in the change step from your orchestration pipeline.

Base system DevOps change model The DevOps change model is included in the base system and is active by default for you to create a model based change request.

Type compatibility flag

The type compatibility com.snc.change_management.change_model.type_compatibility property is used to determine what kind of change requests (type- or model-based) will be created. Navigate to System Properties > All Properties to set the value for this property. The default value of this property is False. This property enables change type compatibility for change models. When set to true, the change request can be created either as a type-based workflow or change models. When set to false, change request will be created only using change model.

The change request will be created based on the configuration combination as defined in the following tables when the property is set to true or false.

Table 1. When the type compatibility property is set to True Change attribute configured in the pipeline step in ServiceNow Change attribute passed in the pipeline Change attribute considered in change request creation Change model: Neither model nor change type is passed. Model-based change request will be created Change model: Type is passed. For example, Normal { "attributes": { "type": "normal" } } Type-based change request will be created Change model: for example, Model 1. Different model is passed. For example, Model 2. { "attributes": { "chg_model": { "name": "Model 2" } } }

Change will be created based on Model 2 Change model: Not specified

Change type:

Neither model nor change type is passed Type-based change request will be created Change type: Model is passed. { "attributes": { "chg_model": { "name": "DevOps" } } } Model-based change request will be created Change type: . For example, Normal Different type is passed. For example, Emergency. { "attributes": { "type": "emergency" } }

Change request will be created based on Emergency type.

Table 2. When the type compatibility property is set to False Change attribute configured in the pipeline step in ServiceNow Change attribute passed in the pipeline Change attribute considered in change request creation Change model: Neither model nor change type is passed Model-based change request will be created Change model: Type is passed. For example, Normal { "attributes": { "type": "normal" } } Error Change request can’t be created because the type compatibility flag is disabled. Enable the type compatibility flag in system properties or configure the change model in the step record in ServiceNow or enter the appropriate change model sys id or name in the pipeline.

For information on resolving this error, see Common errors in DevOps Change Velocity .

Change model: for example, Model 1. Different model is passed. For example, Model 2. { "attributes": { "chg_model": { "name": "Model 2" } } }

Change will be created based on Model 2 Change model: Not specified

Change type:

Neither model nor change type is passed. Error Change request can’t be created because either the change type or change model isn’t configured for the pipeline.

For information on resolving this error, see Common errors in DevOps Change Velocity .

Change type: Model is passed. { "attributes": { "chg_model": { "name": "DevOps" } } } Model-based change request will be created Change type: . For example, Normal Different type is passed. For example, Emergency. { "attributes": { "type": "emergency" } }

Error Change request cannot be created because the type compatibility flag is disabled. Enable the type compatibility flag in system properties or configure the change model in the step record in ServiceNow or enter the appropriate change model sys id or name in the pipeline.

For information on resolving this error, see Common errors in DevOps Change Velocity .

DevOps Model configuration

The base system DevOps change model has the Implementation states field value as Implement, and the Record preset field is selected as Type=Normal by default. The model states available are New, Assess, Scheduled, Implement, Canceled, Authorize, Review, and Closed. Depending on your requirements, you can modify the DevOps change model and configure the states and transitions for your specific use case.

If you want to create your own model instead of using the base system DevOps model, see the instructions in the Create a Change model section.

You can use record presets to configure change details for your change model. Whenever a change is created, these values will be automatically set on the change. You can set a record preset for any change field that exists in the change request.

The following logic is considered for pre-filing the change details when creating a change request. If you have configured change details in the record preset, then you can’t override this value by passing change details from the pipeline. If change details aren’t configured in the record preset, then the values passed from the pipeline is considered for pre-filing the details in the change request. If change details are neither configured in the record preset nor passed from the pipeline, then the values configured in the Step form in ServiceNow are considered.

Change details configured in record preset in ServiceNow Change details configured in Step form in ServiceNow Change details passed in the pipeline Change details pre-filled when change is created Assignment group: DevOps Report Assignment group: Not specified Assignment group: Not specified Assignment group will be pre-filled from the record preset in the change request Assignment group: Not configured Assignment group: Not specified Assignment group: DevOps Report Assignment group will be pre-filled from the pipeline in the change request Assignment group: Not configured Assignment group: DevOps Report Assignment group: Not specified Assignment group will be pre-filled from the Step form in the change request

How the base system DevOps model works?

The DevOps change model contains flows in the base system for state transition and auto change approvals. Each state in the DevOps model has its own flows and each flow will get triggered when the required conditions are met. Change approval (auto or manual) is based on the DevOps Model Change Policy. The following flows explains the state transition and change approval behavior. Change - DevOps - New: When the change request is created in the New state, this flow gets triggered. If it has an Assignment Group, then this flow updates the change state to Assess. Change - DevOps - Assess: When the change request is in the Assess state, this flow gets triggered. There are two key actions in this flow - DevOps Gather Change Policy Data and Apply Change Approval Policy, which are used to retrieve the DevOps data associated with the change request and check whether the change request must be auto approved, auto rejected, or sent for manual approval. The change approval (auto or manual) happens as part of this flow in the Apply Change Approval Policy action based on the DevOps Model Change Policy. If the change is approved (auto or manual), it moves to the Authorize state. If the change is rejected, an email notification is sent to the user who requested the change and the change is moved back to the New state. Change - DevOps - Authorize: When the change request is in the Authorize state, this flow gets triggered. In the base system, you will notice that there are two key actions - DevOps Gather Change Policy Data and Apply Change Approval Policy, which are used to retrieve the DevOps data associated with the change request and check whether the change request must be auto approved, auto rejected, or sent for manual approval. The conditions in the DevOps Model Change Policy in the Apply Change Approval Policy action won't be met. So the change approval (auto or manual) in this flow will be skipped. This flow will only move the change request state to Scheduled that triggers the Change - DevOps - Schedule flow. Note: If your change process requires another approval, you can refer to this flow and customize the DevOps Model Change Policy according to your requirements. Change - DevOps - Schedule: When the change request is in the Scheduled state, this flow gets triggered. When the planned start date is reached, the change is moved to the Implement state. Change - DevOps - Implement: When the change request is in the Implement state, this flow gets triggered. This flow will update the change tasks to the Cancel state, once the change request moves to the Review state.

The DevOps Model Change Policy contains the following policy inputs: code_security code_coverage commits_without_work_item change_request

The three outcomes for the DevOps Model Change Policy (depending on the conditions that you specify) are: 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. Important: When you use the base system DevOps model as is, the change approval is automated by default. If you do not want automated change approval, you can modify the DevOps Model Change Policy in a way it suits your current change process.

Callback to resume the pipeline

In DevOps Change Velocity, the following considerations are made to send a callback request. The implementation states is used to send a callback to the third-party orchestration tool. If only one implementation state is present in the change model, then an absolute comparison is made. When the change created by a change model reaches the implementation state that is set, a call back is sent to the third-party orchestration tool. Note: In change models, the Implementation states field can have one or more states. You can define the implementation states for each change model. For more information, see State model and transitions . If multiple implementation states are present in the change model, a call back is sent to the third-party orchestration tool in the state where implementation state is reached first. If there’s no implementation state set on the change model, then the model states are checked for the Implement state. If the Implement state is present, then that is considered for call back to the third-party orchestration tool. If there’s no implement state in the model states as well, then the value present in the sn_devops.change_request.implement_state property is considered. The value of the system property is -1 by default, which is the implement state. Note: The DevOps Change Request Manual Approval flow is used to send a callback to the third-party orchestration tool. This approval flow waits until the change request is in the Implement state. Once the change request reaches Implement state, this flow updates the Step Execution record to the appropriate (approved, rejected, canceled) state. The moment the Step Execution record is updated, the Change Control Callback flow is triggered to send the callback to the third-party tool. The DevOps Change Request Manual Approval flow is not used for change approvals as the approval is done by the Change request - DevOps - Assess flow in the base system. Ensure that the DevOps Change Request Manual Approval flow is active to send the callback, otherwise the pipeline in the third-party tool will wait and won't resume at all.

After upgrade The Change model field will be displayed in the Step form. This won’t impact your existing type-based change creation process as the type compatibility property ( com.snc.change_management.change_model.type_compatibility ) is true. If you want to have a model-based change request, set the type compatibility property to false. The Change model field in the Step form will be required. For information on configuration combination based on the property, see the table Table 2 .

Note: If you’re an existing customer and zbooted your instance, or a new customer, you can create model-based change requests by default. However, you can create type-based change requests by setting the type compatibility property to true.

The following table explains how the change model feature works for new and upgrading customers. Table 3. Change model behavior based on upgrade New or upgrade instance Type compatibility flag Model or Type State transition flows Auto change approval flows Callback to 3rd party zboot (new or existing zbooted) false DevOps model Change request - DevOps - New Change request - DevOps - Assess Change request - DevOps - Authorize Change request - DevOps - Schedule Change request - DevOps - Implement

In the base system, as described in the How the base system DevOps model works section, change approval (auto or manual) happens through the Change request - DevOps - Assess flow. If you want another level of approval, you can refer to the Change request - DevOps - Authorize flow and customize the DevOps Model Change Policy accordingly. See the Note in the Callback section. Upgrade false DevOps model Change request - DevOps - New Change request - DevOps - Assess Change request - DevOps - Authorize Change request - DevOps - Schedule Change request - DevOps - Implement

In the base system, as described in the How the base system DevOps model works section, change approval (auto or manual) happens through the Change request - DevOps - Assess flow. If you want another level of approval, you can refer to the Change request - DevOps - Authorize flow and customize the DevOps Model Change Policy accordingly. See the Note in the Callback section. Upgrade true Type Current behavior is continued DevOps Change Request Manual Approval, or DevOps Change Request Minimal Automation Approval, or DevOps Change Request Advanced Automation Approval flows (whichever flow is active) Change Control Callback flows

Parent Topic: Accelerating your DevOps change process