DevOps データ検索エラーによる変更要求の作成

DevOps データ検索でエラーが発生した場合でも変更要求を作成します。

変更要求の作成の概要

注:

DevOps データ検索エラーを伴う変更要求の作成は、 Azure DevOps、 GitHub Actions、 GitLab、 Jenkins、およびハーネスパイプラインでのみサポートされています。

DevOps データ検索では、エラーありまたはなしで変更要求を作成できます。この機能は、[ DevOps データ取得でエラーがあっても変更要求の作成を有効にする ] プロパティで制御できます。[ DevOps データ取得でエラーがあっても変更要求の作成を有効にする (Enable change request creation even with errors in DevOps data retrieval )] プロパティが有効になっていて、作業アイテム、コミット、テストサマリー、セキュリティサマリーなどの DevOps データの取得中にエラーが発生した場合でも、対応する変更要求が作成されます。取得できるデータは引き続き変更要求に関連付けられます。取得できないデータについては、エラーの理由がサードパーティコンソールでユーザーに通知され、ステップ実行レコードの [ コメントの変更 ] フィールドと作業 メモの変更にも同じ情報が追加されます。

[DevOps データ検索でエラーがあっても変更要求の作成を有効にする] プロパティが有効になっていない場合、変更要求は、パイプライン実行のどのステップでもエラーがない場合にのみ作成されます。エラーが発生すると、パイプラインが中止され、エラーの理由が受信イベントの [ 処理の詳細 ] フィールドに追加され、サードパーティコンソールでユーザーに同じことが通知されます。

詳細については、「DevOps 変更速度のプロパティ」を参照してください。

DevOps データ検索エラーによる変更要求の承認

DevOps データ検索エラーで作成された変更要求の場合、 is_change_with_partial_data ポリシー入力はすべての変更承認ポリシーに対して True に設定されます。このような変更には手動による変更承認の決定のみが適用されるため、変更内の DevOps データを手動で検証した後に変更を承認または却下できます。[DevOps 変更ポリシーデータの収集] サブフローでは、 Is change with partial data アクションによって、DevOps データ取得エラーが発生した変更が作成されたかどうかが判断されます。

DevOps データ検索エラーのある変更要求のパイプライン UI

DevOps データ検索エラーを含む変更要求が作成されると、エラーが発生したステージを指定するカードが黄色で表示されます。

注:

ビルドパイプライン (CI) がリリース (CD) パイプラインをトリガーするように設定されており、リリースパイプラインに変更が作成されると、データはビルドパイプラインから収集され、変更要求に関連付けられます。ServiceNow DevOps 変更速度管理が、ビルドパイプラインイベントの前にリリースパイプラインイベントを受信して処理する場合があります。この場合、一部のデータの取得中にエラーが発生した場合でも、ビルドパイプラインの DevOps データを使用して変更が作成されます。この動作は、[ DevOps データ取得にエラーがあっても変更要求の作成を有効にする (Enable change request creation even with the errors in the DevOps data retrieval )] プロパティが有効になっている場合でも確認できます。また、この場合、 is_change_with_partial_data ポリシー入力は false になり、DevOps データ取得エラーのある変更要求の場合には常に手動ではなく、承認プロセスは常に手動で適用され、承認フローで定義された方法で適用されます。

コールバックタイムアウト

パイプラインの実行中に受信イベントが待機状態になった場合、システムは sn_devops.change _request_callback_timeout プロパティのタイムアウト値を超えるまで変更の処理を試み、その後パイプラインは中止されます。エラーの理由は、サードパーティツールのコンソールログに表示されます。コールバックタイムアウトのためにパイプラインがキャンセルされると、対応するステップ実行のコールバックレコードに同じ情報が追加されます。DevOps アドミンに連絡して、 sn_devops.change_request_callback_timeout プロパティのタイムアウト値を増やすことができます。このプロパティのデフォルト値は 120 分で、最小値は 60 分です。詳細については、「DevOps 変更速度のプロパティ」を参照してください。

注:

対応するパイプラインで GitHub 変更自動化カスタムアクション、GitLab Docker 変更自動化カスタムアクション、または Harness Docker 変更自動化カスタムアクションを使用して変更要求を作成する場合は、カスタムアクションに 間隔 を指定する必要があります。これにより、GitHub、GitLab、または Harness が ServiceNow DevOps に変更ステータスをポーリングできるようになります。指定された間隔内に ServiceNow で変更が適切なステータスに達すると、変更の結果に応じて適切なステータスが GitHub、GitLab、または Harness パイプラインに送信され、パイプラインが再開または中止されます。詳細については、 GitHub マーケットプレイスからの ServiceNow DevOps カスタムアクション と 汎用 Docker コンテナイメージを使用したパイプラインのカスタムアクションの実装 を参照してください。そのため、変更カスタムアクションを含むパイプラインが実行され、GitHub、GitLab、または Harness からのステップ通知のいずれかが ServiceNow DevOps に到達しなかった場合、ServiceNow DevOps ではコールバック、ステップ実行、およびタスク実行の関連付けは行われません。関連付けが利用できないため、変更は作成されず、ServiceNow DevOps は関連付けが確立されるまで待機します。同時に、GitHub、GitLab、または Harness は、間隔で指定された時間に達するまで、ServiceNow に変更ステータスをポーリングします。この間隔が経過し、 sn_devops.change_request_callback_timeout プロパティで指定されたタイムアウトに達した場合、ServiceNow DevOps はパイプラインを正常に終了せず、最終的にパイプラインを終了する GitHub、GitLab、または Harness ステップで設定されたデフォルトのタイムアウトのままにします。このシナリオで重要な情報は、ServiceNow DevOps では、ステップイベントが ServiceNow DevOps に到達しなかったことを GitHub、GitLab、または Harness のコンソールログでユーザーに通知できないということです。

アップグレード

アップグレード後、このプロパティはデフォルトで false に設定されます。現在の変更プロセスはそのまま機能しますが、唯一の違いは、DevOps データの取得中にエラーが発生すると、パイプラインが (無期限に待機するのではなく) 中断され、エラーの理由が受信イベントの [処理の詳細 ] フィールドに追加され、サードパーティコンソールでユーザーに同じことが通知されることです。DevOps データの取得でエラーが発生している変更要求を作成し、パイプラインを失敗させたくない場合は、[ DevOps データ取得でエラーがあっても変更要求の作成を有効にする ] プロパティを有効にすることができます。これにより、収集され、変更要求の作業メモとサードパーティのコンソールログで適切に通知される DevOps の証拠を使用して自動的に作成された変更を取得し、エラーや欠落している可能性のあるデータを含めることで、変更承認者と AppDev チームに価値を提供します。

制限事項

[ DevOps データ取得でエラーがあっても変更要求の作成を有効にする ] プロパティが有効で、パイプラインの ADO アーティファクトパッケージステップでエラーが発生した場合、変更は ADO アーティファクトが関連付けられずに作成されますが、対応するエラーは、作業メモ、ステップ実行の変更コメント、または ADO コンソールログでは通知されません。