---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# 失敗したビルドまたはリリースパイプラインのジョブとステージの再起動

# 失敗したビルドまたはリリースパイプラインのジョブとステージの再起動 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

そのステージまたはパイプライン Azure DevOps 失敗またはキャンセルされたビルド、リリース変更、またはパイプラインを再実行または再展開します。再試行は、新しい実行を作成するのではなく、 DevOps パイプライン UI に連続実行として表示されます。

## パイプラインまたはステージ Azure DevOps 再実行 {#restart-pipeline-stage-devops-ado__section_hcs_vvq_sqb}

失敗またはキャンセルされたビルドを再実行したり、パイプラインをリリースしたり、 Azure DevOpsでジョブを変更したりできます。再実行は、 ServiceNow DevOpsでの最初の実行と同じパイプライン実行の一部として処理されます。パイプライン全体、または特定の失敗またはキャンセルされたジョブとステージを再実行できます。ステージまたはパイプラインを再起動するたびに新しい変更要求を作成する代わりに、変更要求を再利用することを選択できるようになりました。

ペイロードに attemptNumber パラメーターが追加され、再実行の追跡に役立ちます。関連するテストサマリー、ソフトウェア品質スキャン結果、 コミット、再実行試行ごとに対応する作業アイテムも ServiceNow DevOpsで更新されます。

[Azure Invoke REST API を使用した変更管理の構成](https://servicenow-prod.fluidtopics.net/8AJoaF8NH_DwUgTDiQYvSQ "YAML またはクラシック Azure パイプラインで Azure Invoke REST API を使用して、 DevOpsの変更管理を構成できます。")を使用している場合は、ビルド パイプラインとリリース パイプラインに対して指定された構文形式でペイロード本文に試行番号パラメーターを追加する必要があります。試行回数パラメーターを指定しない場合、デフォルトの試行回数は 1 に設定されます。  
ビルドパイプラインペイロードの試行回数パラメーターの例:

    "attemptNumber": "$(system.jobAttempt)"​

リリースパイプラインペイロードの試行回数パラメーターの例:

    "attemptNumber": "$(Release.AttemptNumber)"

注:  
ステージジョブには、既存の開始通知と完了通知を使用しないでください。ジョブで開始通知と完了通知が考慮される場合、再実行機能は機能しません。

## 変更要求の再利用 {#restart-pipeline-stage-devops-ado__section_z4z_plk_sqb}

変更が有効なジョブが再実行され、前回の実行/試行に対する変更要求が存在する場合は、ベースシステムの「DevOps 変更要求の再利用可能性決定サブフロー」を使用して、前の変更要求を再利用するか、新しい変更要求を作成するかを選択できます。このサブフローのデフォルト実装では、変更要求が実装状況または実装後状況である場合に、前回の試行からの変更要求を再利用できます。変更要求がその他のステータスの場合 (デフォルトでは 、ジョブを再実行すると新しい変更要求が作成されます。既存の動作に従って、テストサマリーやスキャンなどの関連するすべての詳細が新しく生成されますが、新しい変更要求に対してコミットと作業アイテムは変更されずに保持されます。

たとえば、変更要求が承認された後に特定のステージでパイプラインに障害が発生し、そのステージを再実行する場合などです。変更要求が再利用され、関連するテストサマリーとソフトウェア品質スキャン、およびアーティファクトに関連付けられたコミットと作業アイテムが、承認した同じ変更要求に関連付けられます。

再利用性のためにカスタムロジックを適用するには、既存のサブフローをコピーして変更を加え、公開して、 DevOps プロパティDevOps 変更要求の再利用可能性決定サブフロー.

通常のベースシステムフローでは、変更が作成されると、変更要求に対する決定が行われた後に「using-dev-ops-model-change-flow.html」を使用してステップ実行レコードの Stateフィールドが更新されます。ただし、変更を再利用する場合、作成される変更要求の最初のトリガー条件は満たされません。ジョブが再実行 ときに変更要求が再利用されるたびに、「DevOps 変更要求の再利用可能性モデルサブフロー」ベースシステムサブフローが代わりにトリガーされます。このサブフローのデフォルトの実装は、 DevOps モデル変更要求フローと似ています。カスタムサブフローを作成し、サブフロー名を更新できます。 DevOps プロパティDevOps 変更要求の再利用可能性モデルサブフロー.

## パイプライン UI の変更 {#restart-pipeline-stage-devops-ado__section_mdt_zkq_sqb}

ServiceNow DevOps ステージまたはジョブの再起動または再実行時に発生するすべての変更を同期し、 DevOps パイプライン UI に表示します。

* カードをクリックすると、そのステージの最新の試行が表示されます。
* \[ すべての試行を表示\] リンクをクリックすると、すべてのステップ実行と、複数回実行されたステップまたはステージに関連付けられた関連情報が表示されます。
* \[変更を表示\] リンクには、最新の試行に関連付けられた変更要求が表示されます。

{#restart-pipeline-stage-devops-ado__ul_dmb_1xm_vqb}以前のリリースでは、失敗したジョブは無視されるか、再実行のために新しいパイプライン実行ジョブが作成され、それに応じて処理されていました。詳細については、「[DevOps パイプライン UI](https://servicenow-prod.fluidtopics.net/WJq2HvvtdO6vYifGEGxPxQ "パイプライン UI を使用して、パイプライン実行全体のインタラクションと結果を可視化します。このグラフィカル ビューには、各パイプラインのパイプライン ステップの進行状況とその他の詳細が表示されます。")」を参照してください。