DevOps 変更モデル
DevOps チェンジベロシティ を使用すると、目的に適した変更モデルを使用して、最新の開発プラクティスを反映する変更モデルまたは変更プロセスをより柔軟に定義できます。
DevOps 変更モデルの概要
特定のユースケースに合わせて、フローデザイナーに組み込まれた一連の簡潔なフローとフローアクションを備えた目的に適した変更モデルを使用します。変更ワークフロー (通常、標準、緊急) で事前定義された従来の ITIL ベースの変更プロセスを使用する代わりに、特定のユースケース向けに最適化された幅広いモデルに選択的に移行できます。変更モデルは、状況と、状況間の移行を決定するルールを使用して作成できます。変更モデルの詳細については、「 変更モデル」を参照してください。
DevOps または DevOps 簡易変更モデルを含む、ベースシステムの変更モデルのいずれも使用できます。モデルに基づいて変更要求を作成するには、ServiceNow の [ステップ] フォームで [モデル ] フィールドを構成するか、オーケストレーションパイプラインから変更ステップでモデルsys_idまたは名前を渡します。
ベースシステムの DevOps 変更モデル
DevOps と DevOps Simplified という 2 つの変更モデルがベースシステムに含まれており、モデルベースの変更要求を作成できるようにデフォルトで有効になっています。
- タイプ互換性フラグ
-
タイプ互換性 com.snc.change_management.change_model.type_compatibility プロパティは、作成する変更要求の種類 (タイプベースまたはモデルベース) を決定するために使用されます。[システムプロパティ] > [すべてのプロパティ] に移動して、このプロパティの値を設定します。このプロパティのデフォルト値は False です。このプロパティは、変更モデルの変更タイプの互換性を有効にします。true に設定すると、変更要求をタイプベースのワークフローまたは変更モデルとして作成できます。false に設定すると、変更要求は変更モデルのみを使用して作成されます。
変更要求は、プロパティが true または false に設定されている場合、次の表で定義されている構成の組み合わせに基づいて作成されます。
表 : 1. タイプ互換性プロパティが True に設定されている場合 ServiceNow のパイプラインステップで構成された属性を変更する パイプラインで渡された変更属性 変更要求の作成時に考慮される変更属性 変更モデル:<選択した変更モデル> モデルも変更タイプも渡されません。 モデルベースの変更要求が作成されます 変更モデル:<選択した変更モデル> タイプが渡されました。例:[標準] { "attributes": { "type": "normal" } }タイプベースの変更要求が作成されます 変更モデル:<選択した変更モデル> (Model 1 など)。 別のモデルが渡されました。例:モデル 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 チェンジベロシティ」を参照してください。
変更モデル:<選択した変更モデル> (Model 1 など)。 別のモデルが渡されました。例:モデル 2。{ "attributes": { "chg_model": { "name": "Model 2" } } }変更はモデル 2 に基づいて作成されます 変更モデル:未指定
変更タイプ:<選択された任意の変更タイプ>
モデルも変更タイプも渡されません。 エラー 変更タイプまたは変更モデルがパイプライン用に構成されていないため、変更要求を作成できません。
このエラーの解決方法については、「 での一般的なエラー DevOps チェンジベロシティ」を参照してください。
変更タイプ:<選択された任意の変更タイプ> モデルは合格しました。 { "attributes": { "chg_model": { "name": "DevOps" } } }モデルベースの変更要求が作成されます 変更タイプ:<選択した任意の変更タイプ>。例:[標準] 別のタイプが渡されました。たとえば、[緊急] などです。{ "attributes": { "type": "emergency" } }エラー タイプ互換性フラグが無効であるため、変更要求を作成できません。システムのプロパティでタイプ互換性フラグを有効にするか、ServiceNow のステップレコードで変更モデルを設定するか、パイプラインに適切な変更モデルの sys id または名前を入力します。
このエラーの解決方法については、「 での一般的なエラー DevOps チェンジベロシティ」を参照してください。
- DevOps モデルの構成
-
ベースシステムの変更モデルの [ 実装状況 ] フィールドの値は [実装] であり、[ レコードプリセット ] フィールドはデフォルトで [タイプ = 標準 ] として選択されています。DevOps 変更モデルで利用可能なモデルステータスは、[新規]、[評価]、[認可]、[スケジュール済み]、[実装]、[レビュー]、[クローズ済み]、および [キャンセル] です。DevOps 簡易変更モデルで利用可能なモデルステータスは、[新規]、[認可]、[スケジュール済み]、[実装]、[レビュー]、[クローズ済み]、および [キャンセル] です。要件に応じて、変更モデルを変更し、特定のユースケースのステータスと移行を構成できます。
図 : 1. DevOps 変更モデル 図 : 2. DevOps の簡素化された変更モデル ベースシステムの DevOps モデルを使用する代わりに独自のモデルを作成する場合は、 変更モデルの作成 セクションの手順を参照してください。
レコードプリセットを使用して、変更モデルの変更の詳細を構成できます。変更が作成されるたびに、これらの値が変更時に自動的に設定されます。変更要求に存在する任意の変更フィールドのレコードプリセットを設定できます。
変更要求を作成するときに変更の詳細を事前に提出する際には、次のロジックが考慮されます。- レコードプリセットで変更の詳細を構成した場合、パイプラインから変更の詳細を渡してこの値を上書きすることはできません。
- 変更の詳細がレコードプリセットで構成されていない場合、パイプラインから渡された値は、変更要求の詳細を事前に提出するために考慮されます。
- 変更の詳細がレコードプリセットで構成されておらず、パイプラインから渡されていない場合は、ServiceNow のステップフォームで構成された値が考慮されます。
ServiceNow のレコードプリセットで構成された変更の詳細 ServiceNow のステップフォームで構成された変更の詳細 パイプラインで渡された変更の詳細 変更の作成時に事前入力される変更の詳細 アサイン先グループ:DevOps レポート アサイン先グループ:未指定 アサイン先グループ:未指定 アサイン先グループは、変更要求のレコードプリセットから事前入力されます アサイン先グループ:未構成 アサイン先グループ:未指定 アサイン先グループ:DevOps レポート アサイン先グループは、変更要求のパイプラインから事前入力されます アサイン先グループ:未構成 アサイン先グループ:DevOps レポート アサイン先グループ:未指定 アサイン先グループは、変更要求のステップフォームから事前入力されます
DevOps 変更モデル
DevOps 変更モデルには、ステータス移行と変更承認のためのベースシステムのフローが含まれています。DevOps モデルの各ステータスには独自のフローがあり、必要な条件が満たされると各フローがトリガーされます。変更承認 (自動または手動) は、DevOps モデル変更ポリシーに基づきます。デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは、手動承認の決定のみがアクティブ化されます。さらに承認を自動化する準備ができたら、ポリシーを変更できます。次のフローでは、状況移行と変更承認の動作について説明します。- 変更 - DevOps - 新規:変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [評価] に更新します。
- 変更 - DevOps - 評価:変更要求が [評価] ステータスの場合、このフローがトリガーされます。このフローには、[DevOps 変更ポリシーデータの収集] と [変更承認ポリシーの適用] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認、自動却下、または手動承認のために送信する必要があるかどうかを確認するために使用されます。変更承認 (自動または手動) は、DevOps モデル変更ポリシーに基づく [変更承認ポリシーの適用] アクションのこのフローの一部として行われます。変更が承認されると (自動または手動)、承認ステータスに移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更が [新規] ステータスに戻されます。
- 変更 - DevOps - 許可:変更要求が [許可] ステータスの場合、このフローがトリガーされます。ベースシステムでは、DevOps による変更ポリシーデータの収集と変更承認ポリシーの適用という 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認、自動却下、または手動承認のために送信する必要があるかどうかを確認するために使用されます。[変更承認ポリシーの適用 (Apply Change Approval Policy)] アクションの DevOps モデル変更ポリシーの条件が満たされません。したがって、このフローの変更承認 (自動または手動) はスキップされます。このフローは、「変更 - DevOps - スケジュール」フローをトリガーする変更要求ステータスのみを「スケジュール済み」に移行します。 注:変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に応じて DevOps モデル変更ポリシーをカスタマイズできます。
- 変更 - 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
- 自動承認:ポリシーで指定された条件が満たされると、変更要求が自動的に承認されます。
- 自動却下:ポリシーで指定された 1 つ以上の条件が満たされない場合、変更要求は自動的に却下されます。
- 手動承認:ポリシーで指定されたユーザーまたはグループによる手動承認が必要な条件が 1 つ以上ある場合。手動での承認を迅速化して変更要求を進めるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。注:デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは、手動承認の決定のみがアクティブ化されます。
DevOps 簡素化されたモデル
- 変更 - DevOps 簡素化 - 新規:変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [評価] に更新します。
- 変更 - DevOps 簡素化 - 許可:変更要求が [許可] ステータスの場合、このフローがトリガーされます。このフローには、[DevOps 変更ポリシーデータの収集] と [変更承認ポリシーの適用] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認、自動却下、または手動承認のために送信する必要があるかどうかを確認するために使用されます。変更承認 (自動または手動) は、DevOps 簡易モデル変更ポリシーに基づく [変更承認ポリシーの適用] アクションのこのフローの一部として行われます。変更が承認されると (自動または手動)、 [スケジュール] ステータスに移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更が [新規] ステータスに戻されます。 注:変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に応じて DevOps 簡易モデル変更ポリシーをカスタマイズできます。
- 変更 - 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
- 自動承認:ポリシーで指定された条件が満たされると、変更要求が自動的に承認されます。
- 自動却下:ポリシーで指定された 1 つ以上の条件が満たされない場合、変更要求は自動的に却下されます。
- 手動承認:ポリシーで指定されたユーザーまたはグループによる手動承認が必要な条件が 1 つ以上ある場合。手動での承認を迅速化して変更要求を進めるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。注:デフォルトでは、ベースシステムの DevOps 簡易モデル変更ポリシーでは、手動承認の決定のみがアクティブ化されています。
パイプラインを再開するためのコールバック
- 実装ステータスは、サードパーティのオーケストレーションツールにコールバックを送信するために使用されます。変更モデルに実装ステータスが 1 つのみ存在する場合は、絶対比較が行われます。変更モデルによって作成された変更が設定された実装ステータスに達すると、コールバックがサードパーティのオーケストレーションツールに送信されます。注:変更モデルでは、[実装状況] フィールドに 1 つ以上の状況を指定できます。変更モデルごとに実装状況を定義できます。詳細については、「状況モデルと移行」を参照してください。
- 変更モデルに複数の実装状況が存在する場合は、最初に実装状況に到達した状況のサードパーティのオーケストレーションツールにコールバックが送信されます。
- 変更モデルに実装ステータスが設定されていない場合、モデルステータスは 実装 ステータスとしてチェックされます。[実装] ステータスが存在する場合は、サードパーティのオーケストレーションツールへのコールバックが考慮されます。モデル状況にも実装ステータスがない場合は、 sn_devops.change_request.implement_state プロパティに存在する値が考慮されます。システムプロパティの値はデフォルトで -1 で、これは実装ステータスです。
アップグレード後
- [ 変更モデル ] フィールドがステップフォームに表示されます。タイプ互換性プロパティ (com.snc.change_management.change_model.type_compatibility) が true であるため、これは既存のタイプベースの変更作成プロセスには影響しません。
- モデルベースの変更要求が必要な場合は、型互換性プロパティを false に設定します。[ステップ] フォームの [ 変更モデル ] フィールドは必須になります。プロパティに基づく構成の組み合わせについては、表 型互換性プロパティが False に設定されている場合を参照してください。
| 新規またはアップグレードインスタンス | タイプ互換性フラグ | モデルまたはタイプ | 状況移行フロー | 自動変更承認フロー | サードパーティへのコールバック |
|---|---|---|---|---|---|
| zboot (新規または既存の zbooted) | false | DevOps モデル |
|
ベースシステムでは、変更承認 (自動または手動) は、変更要求 - DevOps - 評価フローを介して行われます。別のレベルの承認が必要な場合は、「変更要求 - DevOps - 承認」フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 | 「コールバック」セクションの 注意 を参照してください。 |
| アップグレード | false | DevOps モデル |
|
ベースシステムでは、変更承認 (自動または手動) は、変更要求 - DevOps - 評価フローを介して行われます。別のレベルの承認が必要な場合は、「変更要求 - DevOps - 承認」フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 | 「コールバック」セクションの 注意 を参照してください。 |
| zboot (新規または既存の zbooted) | false | DevOps 簡素化されたモデル |
|
ベースシステムでは、変更要求 - DevOps - 承認フローを介して変更承認 (自動または手動) が行われます。別のレベルの承認が必要な場合は、それに応じて DevOps 簡素化モデル変更ポリシーをカスタマイズできます。 | 「コールバック」セクションの 注意 を参照してください。 |
| アップグレード | false | DevOps 簡素化されたモデル |
|
ベースシステムでは、変更要求 - DevOps - 承認フローを介して変更承認 (自動または手動) が行われます。別のレベルの承認が必要な場合は、それに応じて DevOps 簡素化モデル変更ポリシーをカスタマイズできます。 | 「コールバック」セクションの 注意 を参照してください。 |
| アップグレード | true | タイプ | 現在の動作は継続されます | DevOps 変更要求の手動承認、DevOps 変更要求の最小自動化承認、または DevOps 変更要求の高度な自動化承認フロー (いずれかのアクティブなフロー) | 変更コントロールコールバックフロー |