DevOps change models

  • Release version: Washingtondc
  • Updated August 1, 2024
  • 15 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of DevOps Change Models

    DevOps Change Velocity allows for the adoption of flexible change models that better align with modern development practices. Customers are encouraged to utilize the Change Management - Change Models feature for optimally managing change requests, moving away from traditional ITIL-based processes.

    Show full answer Show less

    Key Features

    • Fit-for-purpose Change Models: Options include the DevOps and DevOps Simplified models, which can be customized for specific use cases.
    • Type Compatibility: The type compatibility property determines how change requests are created, allowing either model-based or type-based creation depending on the setting.
    • State Transition Flows: Defined flows for each state within the change models automate the change approval process based on set conditions.
    • Record Presets: Automatically configure change details during the creation of change requests based on preset values.

    Key Outcomes

    By implementing these change models, ServiceNow customers can expect improved flexibility in managing change requests, leading to faster and more efficient workflows. The automation of approvals and customizable policies enhances the ability to meet specific organizational needs while minimizing delays in the change process.

    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.

    DevOps Change model 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 and DevOps Simplified change models are 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.

    Change models

    You can use any of the base system change models including the DevOps or DevOps Simplified change models. 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 models

    Two change models, called DevOps and DevOps Simplified are included in the base system and are 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: <any selected change model> Neither model nor change type is passed. Model-based change request will be created
    Change model: <any selected change model> Type is passed. For example, Normal
    {
    "attributes": {
      "type": "normal"
    }
  }
    		 Type-based change request will be created
    Change model: <any selected 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: <any selected change type>

    		 Neither model nor change type is passed Type-based change request will be created
    Change type: <any selected change type> Model is passed. 
    {
    "attributes": {
      "chg_model": {
         "name": "DevOps"
      }
    }
  }
    		 Model-based change request will be created
    Change type: <any selected 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: <any selected change model> Neither model nor change type is passed Model-based change request will be created
    Change model: <any selected 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: <any selected 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: <any selected 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: <any selected change type> Model is passed.
    {
    "attributes": {
      "chg_model": {
         "name": "DevOps"
      }
    }
  }
    		 Model-based change request will be created
    Change type: <any selected 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.
    Configuration of DevOps models

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

    Figure 1. DevOps Change Model
    DevOps change model
    Figure 2. DevOps Simplified Change Model
    DevOps Simplified Change Model

    If you want to create your own model instead of using the base system DevOps models, 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

    DevOps Change model

    The DevOps change model contains flows in the base system for state transition and 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. By default, the base system DevOps Model Change Policy only has the manual approval decision activated. When you are ready for more approval automation, you can modify the policy. The following flows explain 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 - Assess flow
    • 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.
    The DevOps Model Change Policy contains the following policy inputs:
    • is_change_with_partial_data
    • regression_tests_failed
    • code_security
    • code_coverage
    • total_num_of_commits
    • tests_passing_percent
    • load_tests_failed
    • num_of_open_incidents
    • num_of_outages_in_last_7_days
    • num_of_current_outages
    • integration_tests_failed
    • commits_without_work_item
    • change_request
    • risk
    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.
      Note:
      By default, the base system DevOps Model Change Policy only has the manual approval decision activated.
    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.

    DevOps Simplified model

    The DevOps Simplified change model contains flows in the base system for state transition and change approvals. Each state in the DevOps Simplified 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 Simplified Model Change Policy. The following flows explains the state transition and change approval behavior.
    • Change - DevOps Simplified - 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 Simplified - Authorize: When the change request is in the Authorize 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 Simplified Model Change Policy. If the change is approved (auto or manual), it moves to the Schedule 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.
      Note:
      If your change process requires another approval, you can refer to this flow and customize the DevOps Simplified Model Change Policy according to your requirements.
      Change - DevOps Simplified - Authorize flow
    • Change - DevOps Simplified- 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 Simplified - Implement: When the change request is in the Implement state, this flow gets triggered.
    The DevOps Simplified Model Change Policy contains the following policy inputs:
    • is_change_with_partial_data
    • regression_tests_failed
    • code_security
    • code_coverage
    • total_num_of_commits
    • tests_passing_percent
    • load_tests_failed
    • num_of_open_incidents
    • num_of_outages_in_last_7_days
    • num_of_current_outages
    • integration_tests_failed
    • commits_without_work_item
    • change_request
    • risk
    The three outcomes for the DevOps Simplified 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.
      Note:
      By default, the base system DevOps Simplified Model Change Policy only has the manual approval decision activated.

    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 Change – DevOps – Update execution state 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.

    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 When the type compatibility property is set to False.
    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, 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, 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.
    zboot (new or existing zbooted) false DevOps Simplified model
    • Change request - DevOps - New
    • Change request - DevOps - Authorize
    • Change request - DevOps - Schedule
    • Change request - DevOps - Implement
    		 In the base system, change approval (auto or manual) happens through the Change request - DevOps - Authorize flow. If you want another level of approval, you can customize the DevOps Simplified Model Change Policy accordingly. See the Note in the Callback section.
    Upgrade false DevOps Simplified 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, change approval (auto or manual) happens through the Change request - DevOps - Authorize flow. If you want another level of approval, you can customize the DevOps Simplified 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