DevOps 変更モデル

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間:20分
  • DevOps チェンジベロシティ を使用すると、目的に合った変更モデルを使用できます。これにより、最新の開発プラクティスを反映する変更モデルまたはプロセスをより柔軟に定義できます。

    DevOps 変更モデルの概要

    重要:
    DevOps 変更要求の場合は、変更管理 - 変更モデル機能を使用します。これにより、特定のユースケース向けに最適化された方法で変更プロセスフローをより柔軟に有効にできます。詳細については、「変更モデル」を参照してください。従来の [変更管理 - 状況モデル] もサポートされています。詳細については、「状況モデルと移行」を参照してください。
    重要:
    DevOps および DevOps 簡素化された変更モデルは、Argo CD および分割ツールの変更要求ではサポートされていません。

    特定のユースケース向けに、Flow Designer で構築された一連の簡潔なフローとフローアクションで目的に合った変更モデルを使用します。変更ワークフロー (通常、標準、緊急) で事前定義された従来の ITIL ベースの変更プロセスを使用する代わりに、特定のユースケースに最適化された幅広いモデルに選択的に移行できます。変更モデルは、ステータス間の移行を決定するステータスとルールを使用して作成できます。変更モデルの詳細については、「 変更モデル」を参照してください。

    変更モデル

    DevOps または DevOps 簡素化された変更モデルを含む、任意のベースシステム変更モデルを使用できます。モデルに基づいて変更要求を作成するには、ServiceNow のステップフォームで [モデル ] フィールドを設定するか、オーケストレーションパイプラインから変更ステップでモデルsys_idまたは名前を渡します。

    ベースシステムの DevOps 変更モデル

    DevOps および DevOps Simplify と呼ばれる 2 つの変更モデルがベースシステムに含まれており、モデルベースの変更要求を作成するためにデフォルトで有効になっています。

    タイプ互換性フラグ

    タイプ互換性 com.snc.change_management.change_model.type_compatibility プロパティは、作成される変更要求の種類 (タイプベースまたはモデルベース) を決定するために使用されます。[ システムプロパティ] > [すべてのプロパティ ] に移動して、このプロパティの値を設定します。このプロパティのデフォルト値は False です。このプロパティは、変更モデルの変更タイプの互換性を有効にします。true に設定すると、変更要求はタイプベースのワークフローまたは変更モデルのいずれかとして作成できます。false に設定すると、変更要求は変更モデルのみを使用して作成されます。

    プロパティが true または false に設定されている場合、変更要求は、次の表で定義されている構成の組み合わせに基づいて作成されます。

    表 : 1. 型互換性プロパティが True に設定されている場合
    ServiceNow のパイプラインステップで構成された属性の変更 パイプラインで渡された変更属性 変更要求の作成で考慮される変更属性
    変更モデル : <選択した任意の変更モデル> モデルも変更タイプも渡されません。 モデルベースの変更要求が作成されます
    変更モデル : <選択した任意の変更モデル> タイプが渡されます。たとえば、通常
    {
        "attributes": {
          "type": "normal"
        }
      }
    タイプベースの変更要求が作成されます
    変更モデル:<選択した任意の変更モデル> (モデル 1 など)。
    異なるモデルが渡されます。たとえば、Model 2 などです。
    {
        "attributes": {
          "chg_model": {
             "name": "Model 2"
            }
          }
      }
    変更はモデル 2 に基づいて作成されます

    変更モデル:未指定

    変更タイプ:<選択した任意の変更タイプ>

    モデルも変更タイプも渡されません タイプベースの変更要求が作成されます
    変更タイプ:<選択した任意の変更タイプ> モデルが渡されます。
    {
        "attributes": {
          "chg_model": {
             "name": "DevOps"
          }
        }
      }
    モデルベースの変更要求が作成されます
    変更タイプ:<選択した任意の変更タイプ>。たとえば、通常
    別の型が渡されます。たとえば、緊急です。
    {
        "attributes": {
          "type": "emergency"
        }
      }
    変更要求は緊急タイプに基づいて作成されます。
    表 : 2. 型互換性プロパティが False に設定されている場合
    ServiceNow のパイプラインステップで構成された属性の変更 パイプラインで渡された変更属性 変更要求の作成で考慮される変更属性
    変更モデル : <選択した任意の変更モデル> モデルも変更タイプも渡されません モデルベースの変更要求が作成されます
    変更モデル : <選択した任意の変更モデル> タイプが渡されます。たとえば、通常
    {
        "attributes": {
          "type": "normal"
        }
      }
    エラー

    タイプ互換性フラグが無効になっているため、変更要求を作成できません。システムプロパティでタイプ互換性フラグを有効にするか、ServiceNow のステップレコードで変更モデルを設定するか、パイプラインに適切な変更モデルの sys id または名前を入力します。

    このエラーの解決方法については、「 の一般的なエラー DevOps チェンジベロシティ」を参照してください。

    変更モデル:<選択した任意の変更モデル> (モデル 1 など)。
    異なるモデルが渡されます。たとえば、Model 2 などです。
    {
        "attributes": {
          "chg_model": {
             "name": "Model 2"
          }
        }
      }
    変更はモデル 2 に基づいて作成されます

    変更モデル:未指定

    変更タイプ:<選択した任意の変更タイプ>

    モデルも変更タイプも渡されません。 エラー

    変更タイプまたは変更モデルがパイプライン用に構成されていないため、変更要求を作成できません。

    このエラーの解決方法については、「 の一般的なエラー DevOps チェンジベロシティ」を参照してください。

    変更タイプ:<選択した任意の変更タイプ> モデルが渡されます。
    {
        "attributes": {
          "chg_model": {
             "name": "DevOps"
          }
        }
      }
    モデルベースの変更要求が作成されます
    変更タイプ:<選択した任意の変更タイプ>。たとえば、通常
    別の型が渡されます。たとえば、緊急です。
    {
        "attributes": {
          "type": "emergency"
        }
      }
    エラー

    タイプ互換性フラグが無効になっているため、変更要求を作成できません。システムプロパティでタイプ互換性フラグを有効にするか、ServiceNow のステップレコードで変更モデルを設定するか、パイプラインに適切な変更モデルの sys id または名前を入力します。

    このエラーの解決方法については、「 の一般的なエラー DevOps チェンジベロシティ」を参照してください。

    DevOps モデルの構成

    ベースシステムの変更モデルでは、[ 実装ステータス ] フィールドの値は [実装] に設定され、[ レコードプリセット ] フィールドはデフォルトで [タイプ] = [通常] として選択されています。DevOps 変更モデルで利用可能なモデルステータスは、[新規]、[評価]、[認可]、[スケジュール済み]、[実装]、[レビュー]、[クローズ済み]、および [キャンセル済み] です。また、DevOps の簡素化された変更モデルで利用可能なモデルステータスは、[New (新規)]、[Authorize (許可)]、[Scheduled (スケジュール済み)]、[Implement (実装)]、[Review (レビュー)]、[Closed (クローズ済み)]、および [Canceled (キャンセル済み)] です。要件に応じて、変更モデルを変更し、特定のユースケースのステータスと移行を設定できます。

    図 : 1. DevOps 変更モデル
    DevOps 変更モデル
    図 : 2. DevOps の簡素化された変更モデル
    DevOps の簡素化された変更モデル

    ベースシステムの DevOps モデルを使用する代わりに独自のモデルを作成する場合は、「 変更モデルの作成 」セクションの手順を参照してください。

    レコードプリセットを使用して、変更モデルの変更の詳細を設定できます。変更が作成されるたびに、これらの値が自動的に変更に設定されます。変更要求に存在する任意の変更フィールドに対してレコードプリセットを設定できます。

    変更要求の作成時に変更の詳細を事前提出する際には、次のロジックが考慮されます。
    • レコードプリセットで変更の詳細を構成した場合、パイプラインから変更の詳細を渡してこの値を上書きすることはできません。
    • 変更の詳細がレコードプリセットで構成されていない場合、パイプラインから渡された値は、変更要求の詳細を事前提出するために考慮されます。
    • 変更の詳細がレコードプリセットで構成されておらず、パイプラインから渡されない場合は、ServiceNow のステップフォームで構成された値が考慮されます。
    ServiceNow のレコードプリセットで構成された変更の詳細 ServiceNow のステップフォームで構成された変更の詳細 パイプラインで渡される変更の詳細 変更の作成時に事前入力される変更の詳細
    アサイン先グループ:DevOps レポート アサイン先グループ:未指定 アサイン先グループ:未指定 アサイン先グループは、変更要求のレコードプリセットから事前入力されます
    アサイン先グループ:未構成 アサイン先グループ:未指定 アサイン先グループ:DevOps レポート アサイン先グループは、変更要求のパイプラインから事前入力されます
    アサイン先グループ:未構成 アサイン先グループ:DevOps レポート アサイン先グループ:未指定 アサイン先グループは、変更要求のステップフォームから事前に入力されます

    DevOps 変更モデル

    DevOps 変更モデルには、状況移行と変更承認のためのベースシステムのフローが含まれています。DevOps モデルの各ステータスには独自のフローがあり、必要な条件が満たされると各フローがトリガーされます。変更承認 (自動または手動) は、DevOps モデル変更ポリシーに基づいています。デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは手動承認の決定のみがアクティブ化されています。さらに承認を自動化する準備ができたら、ポリシーを変更できます。次のフローでは、状況移行と変更承認の動作について説明します。
    • 変更 - DevOps - 新規:変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [Assess] に更新します。
    • 変更 - DevOps - 評価:変更要求が [評価] ステータスの場合、このフローがトリガーされます。このフローには、[DevOps による変更ポリシーデータの収集] と [変更承認ポリシーの適用] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認するか、自動却下するか、手動承認のために送信する必要があるかを確認するために使用されます。変更の承認 (自動または手動) は、DevOps モデル変更ポリシーに基づく変更承認ポリシーの適用アクションのこのフローの一部として行われます。変更が承認されると (自動または手動)、ステータスは [Authorize] に移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更は [新規] 状態に戻ります。変更 - DevOps - 評価フロー
    • 変更 - DevOps - 許可:変更要求が [許可] ステータスになると、このフローがトリガーされます。ベースシステムには、[DevOps による変更ポリシーデータの収集 (DevOps Gather Change Policy Data)] と [変更承認ポリシーの適用 (Apply Change Approval Policy)] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認するか、自動却下するか、手動承認のために送信する必要があるかを確認するために使用されます。[変更承認ポリシーの適用 (Apply Change Approval Policy)] アクションの DevOps モデル変更ポリシーの条件が満たされません。したがって、このフローの変更承認 (自動または手動) はスキップされます。このフローは、変更 - DevOps - スケジュールフローをトリガーする変更要求ステータスをスケジュール済みに移行するだけです。
      注:
      変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に従って DevOps モデル変更ポリシーをカスタマイズできます。
    • 変更 - DevOps - スケジュール:変更要求が [スケジュール済み] ステータスの場合、このフローがトリガーされます。開始予定日に達すると、変更は [Implement] ステータスに移行します。
    • 変更 - DevOps - 実装:変更要求が [実装] ステータスになると、このフローがトリガーされます。
    DevOps モデル変更ポリシーには、次のポリシー入力が含まれています。
    • 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
    DevOps モデル変更ポリシーの 3 つの結果 (指定した条件による) は次のとおりです。
    • 自動承認:ポリシーで指定された条件が満たされた場合、変更要求は自動的に承認されます。
    • 自動却下:ポリシーで指定された 1 つ以上の条件が満たされない場合、変更要求は自動的に却下されます。
    • 手動承認:1 つ以上の条件がユーザーまたはグループによる手動承認を必要とする場合、それはポリシーで指定されています。手動承認を迅速化し、変更要求を進行させるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。
      注:
      デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは手動承認の決定のみがアクティブ化されています。
    重要:
    ベースシステムの DevOps モデルをそのまま使用すると、変更の承認はデフォルトで自動化されます。自動変更承認が必要ない場合は、現在の変更プロセスに適した方法で DevOps モデル変更ポリシーを変更できます。

    DevOps 簡素化されたモデル

    DevOps の簡素化された変更モデルには、状況移行と変更承認のためのベースシステムのフローが含まれています。DevOps 簡易モデルの各ステータスには独自のフローがあり、必要な条件が満たされると各フローがトリガーされます。変更承認 (自動または手動) は、DevOps 簡素化されたモデル変更ポリシーに基づいています。次のフローでは、状況移行と変更承認の動作について説明します。
    • 変更 - DevOps 簡略化 - 新規:変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [Assess] に更新します。
    • 変更 - DevOps 簡略化 - 許可:変更要求が [許可] ステータスになると、このフローがトリガーされます。このフローには、[DevOps による変更ポリシーデータの収集] と [変更承認ポリシーの適用] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認するか、自動却下するか、手動承認のために送信する必要があるかを確認するために使用されます。変更承認 (自動または手動) は、DevOps 簡素化モデル変更ポリシーに基づく変更承認ポリシーの適用アクションのこのフローの一部として行われます。変更が (自動または手動) 承認されると、[スケジュール] ステータスに移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更は [新規] 状態に戻ります。
      注:
      変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に従って DevOps 簡素化モデル変更ポリシーをカスタマイズできます。
      変更 - DevOps の簡素化 - 許可フロー
    • 変更 - DevOps 簡略化 - スケジュール:変更要求が [スケジュール済み] ステータスの場合、このフローがトリガーされます。開始予定日に達すると、変更は [Implement] ステータスに移行します。
    • 変更 - DevOps 簡略化 - 実装:変更要求が [実装] ステータスの場合、このフローがトリガーされます。
    DevOps 簡素化されたモデル変更ポリシーには、次のポリシー入力が含まれています。
    • 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
    DevOps 簡素化されたモデル変更ポリシーの 3 つの結果 (指定した条件によって異なります) は次のとおりです。
    • 自動承認:ポリシーで指定された条件が満たされた場合、変更要求は自動的に承認されます。
    • 自動却下:ポリシーで指定された 1 つ以上の条件が満たされない場合、変更要求は自動的に却下されます。
    • 手動承認:1 つ以上の条件がユーザーまたはグループによる手動承認を必要とする場合、それはポリシーで指定されています。手動承認を迅速化し、変更要求を進行させるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。
      注:
      デフォルトでは、ベースシステムの DevOps 簡素化されたモデル変更ポリシーでは、手動承認の決定のみがアクティブ化されています。

    パイプラインを再開するコールバック

    DevOps チェンジベロシティでは、コールバック要求を送信する際に次の考慮事項があります。
    • 実装ステータスは、サードパーティのオーケストレーションツールにコールバックを送信するために使用されます。変更モデルに実装ステータスが 1 つしか存在しない場合は、絶対比較が行われます。変更モデルによって作成された変更が設定された実装ステータスに達すると、コールバックがサードパーティのオーケストレーションツールに送信されます。
      注:
      変更モデルでは、[実装ステータス] フィールドに 1 つ以上のステータスを設定できます。変更モデルごとに実装ステータスを定義できます。詳細については、「状況モデルと移行」を参照してください。
    • 変更モデルに複数の実装ステータスが存在する場合、実装ステータスに最初に到達したステータスのサードパーティオーケストレーションツールにコールバックが送信されます。
    • 変更モデルに実装ステータスが設定されていない場合、モデルステータスで [実装 ] ステータスがチェックされます。[実装] ステータスが存在する場合は、サードパーティのオーケストレーションツールへのコールバックが考慮されます。モデルステータスにも実装ステータスがない場合は、 sn_devops.change_request.implement_state プロパティに存在する値が考慮されます。システムプロパティの値はデフォルトで -1 で、これが実装ステータスです。
    注:
    変更 – DevOps – 実行ステータスの更新フローは、サードパーティのオーケストレーションツールにコールバックを送信するために使用されます。この承認フローは、変更要求が [実装] ステータスになるまで待機します。変更要求が実装ステータスに達すると、このフローはステップ実行レコードを適切なステータス (承認済み、却下済み、キャンセル済み) に更新します。ステップ実行レコードが更新されると、変更管理コールバックフローがトリガーされ、コールバックがサードパーティツールに送信されます。

    アップグレード後

    • [Change model (変更モデル)] フィールドが [Step (ステップ)] フォームに表示されます。タイプ互換性プロパティ (com.snc.change_management.change_model.type_compatibility) が true であるため、これは既存のタイプベースの変更作成プロセスには影響しません。
    • モデルベースの変更要求が必要な場合は、タイプ互換性プロパティを false に設定します。ステップフォームの [Change model ] フィールドは必須です。プロパティに基づく構成の組み合わせについては、表 型互換性プロパティが False に設定されている場合を参照してください。
    注:
    インスタンスを zboot した既存の顧客、または新規の顧客の場合、デフォルトでモデルベースの変更要求を作成できます。ただし、タイプ互換性プロパティを true に設定することで、タイプベースの変更要求を作成できます。
    次の表は、新規顧客およびアップグレード顧客に対して変更モデル機能がどのように機能するかを示しています。
    表 : 3. アップグレードに基づくモデルの動作の変更
    新規またはアップグレードインスタンス タイプ互換性フラグ モデルまたはタイプ 状況移行フロー 自動変更承認フロー サードパーティへのコールバック
    zboot (新規または既存の zbooted) false DevOps モデル
    • 変更要求:DevOps:新規
    • 変更要求:DevOps:評価
    • 変更要求:DevOps:許可
    • 変更要求:DevOps:スケジュール
    • 変更要求 - DevOps - 実装
    ベースシステムでは、変更の承認 (自動または手動) は変更要求 - DevOps - 評価フローを通じて行われます。別のレベルの承認が必要な場合は、変更要求:DevOps:許可フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 [コールバック] セクションの メモ を参照してください。
    アップグレード false DevOps モデル
    • 変更要求:DevOps:新規
    • 変更要求:DevOps:評価
    • 変更要求:DevOps:許可
    • 変更要求:DevOps:スケジュール
    • 変更要求 - DevOps - 実装
    ベースシステムでは、変更の承認 (自動または手動) は変更要求 - DevOps - 評価フローを通じて行われます。別のレベルの承認が必要な場合は、変更要求:DevOps:許可フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 [コールバック] セクションの メモ を参照してください。
    zboot (新規または既存の zbooted) false DevOps 簡素化されたモデル
    • 変更要求:DevOps:新規
    • 変更要求:DevOps:許可
    • 変更要求:DevOps:スケジュール
    • 変更要求 - DevOps - 実装
    ベースシステムでは、変更の承認 (自動または手動) は変更要求 - DevOps - 許可フローを通じて行われます。別のレベルの承認が必要な場合は、それに応じて DevOps 簡素化モデル変更ポリシーをカスタマイズできます。 [コールバック] セクションの メモ を参照してください。
    アップグレード false DevOps 簡素化されたモデル
    • 変更要求:DevOps:新規
    • 変更要求:DevOps:評価
    • 変更要求:DevOps:許可
    • 変更要求:DevOps:スケジュール
    • 変更要求 - DevOps - 実装
    ベースシステムでは、変更の承認 (自動または手動) は変更要求 - DevOps - 許可フローを通じて行われます。別のレベルの承認が必要な場合は、それに応じて DevOps 簡素化モデル変更ポリシーをカスタマイズできます。 [コールバック] セクションの メモ を参照してください。
    アップグレード true タイプ 現在の動作は継続されます DevOps 変更要求の手動承認、DevOps 変更要求の最小限の自動化承認、または DevOps 変更要求の高度な自動化承認フロー (アクティブなフロー) 変更管理コールバックフロー