DevOps 変更要求属性

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：5分

    • パイプライン、更新関数、または自動フローを介して属性を渡し、changeInfo REST API (デフォルトの変更ハンドラーサブフロー) を使用して、DevOps 変更要求属性を追加または更新します。

    属性の指定

    変更要求属性を指定するには、次のいずれかの方法を使用します。

    検討の優先順位

    変更属性が複数のメソッドで指定されている場合、属性値が考慮される優先順位は異なります。ServiceNow では、DevOps 変更速度管理のパイプラインステップ、デフォルトの変更ハンドラーサブフロー、または承認フローで属性を指定できます。オーケストレーションツールのパイプラインでは、属性をパイプラインステップで渡すか、REST API を使用して渡すことができます。変更モデルを使用する場合は、モデルプリセットで指定することもできます。

    値が考慮される優先順位を理解するには、次の表と例を参照してください。

    表 : 1. タイプベースの変更の変更属性の優先順位
    変更要求 [Precedence (優先順位)]
    Standard
    1. パイプラインを介して渡された変更属性
    2. ServiceNow のステップレコードフィールド
    3. パイプラインを介して変更属性に渡されるテンプレート
    4. ServiceNow のステップフィールドのテンプレート
    非標準
    1. パイプラインを介して渡された変更属性
    2. デフォルトの変更ハンドラーサブフローと承認フロー
      重要:
      デフォルトの変更ハンドラーサブフローと承認フローの両方で属性値を設定すると、同時に実行される可能性があるため、競合が発生する可能性があります。問題を回避するには、1 つのソースにのみ属性値を設定します。
    3. ServiceNow のステップレコードフィールド
    4. パイプラインを介して変更属性に渡されるテンプレート
    5. ServiceNow のステップフィールドのテンプレート
    表 : 2. モデルベースの変更の変更属性の優先順位
    変更要求 [Precedence (優先順位)]
    Standard
    1. モデルプリセット
    2. パイプラインを介して渡された変更属性
    3. ServiceNow のステップレコードフィールド
    4. パイプラインを介して変更属性に渡されるテンプレート
    5. ServiceNow のステップフィールドのテンプレート
    非標準
    1. モデルプリセット
    2. パイプラインを介して渡された変更属性
    3. デフォルトの変更ハンドラーサブフローと承認フロー
      重要:
      デフォルトの変更ハンドラーサブフローと承認フローの両方で属性値を設定すると、同時に実行される可能性があるため、競合が発生する可能性があります。問題を回避するには、1 つのソースにのみ属性値を設定します。
    4. ServiceNow のステップレコードフィールド
    5. パイプラインを介して変更属性に渡されるテンプレート
    6. ServiceNow のステップフィールドのテンプレート
    注:
    変更操作でビジネスルールを使用している場合は、 sn_devops.change_request.apply_attributes_on_creation プロパティを true に設定して、変更要求の作成後に渡される属性ではなく、変更要求の作成時にパイプラインで渡される変更属性が設定されるようにする必要があります。詳細については、「DevOps チェンジベロシティのプロパティ」を参照してください。

    シナリオ 1

    属性が ServiceNow のデフォルトの変更ハンドラーサブフローとオーケストレーションパイプラインの更新機能で指定されているシナリオを考えてみましょう。assignment_group属性がデフォルトの変更ハンドラーサブフローで「change mgmt」として指定され、パイプラインの更新機能で「CAB」として指定されているとします。このシナリオでは、変更が作成されるときに、デフォルトの変更ハンドラーサブフローの値が考慮され、「変更管理」がassignment_groupで考慮される値になります。変更が承認され、パイプラインが再開されると、更新機能で指定された値 ("CAB" など) が考慮されます。

    シナリオ 2

    属性が ServiceNow のデフォルトの変更ハンドラーサブフローとオーケストレーションパイプラインの変更ステップで指定されているシナリオを考えてみましょう。assignment_group属性がデフォルトの変更ハンドラーサブフローで「change mgmt」として指定され、パイプラインの変更ステップで「chg mgmt1」として指定されているものとします。このシナリオでは、変更が作成されると、変更ステップ (chg mgmt1) の値が考慮され、既定の変更ハンドラー サブフローがトリガーされると、考慮される値は "change mgmt" になります。

    シナリオ 3

    変更属性とステップレコードのテンプレートで渡されたテンプレートを通じて属性が指定されるシナリオを考えてみましょう。assignment_group属性は、変更属性で渡されたテンプレートで "change mgmt" として指定され、パイプライン ステップ レコードのテンプレートで "chg mgmt1" として指定されているものとします。このシナリオでは、変更が作成されるときに、変更属性 (chg mgmt) に渡されたテンプレートの値が考慮されます。

    シナリオ 4

    モデルベースの変更の変更属性とモデルプリセットで属性が指定されているシナリオを考えてみましょう。assignment_group属性が変更属性で「change mgmt」として指定され、モデルプリセットで「chg mgmt1」として指定されているものとします。このシナリオでは、変更が作成されるときに、モデル プリセット (chg mgmt1) の値が考慮されます。