デフォルトの動作（強制再デプロイなし）

が force-redeploy 設定されていないか、 false に設定されている場合、パイプラインは対象環境のインベントリリポジトリで新しい変更が検出されたときにのみデプロイされます。

1. CDパイプラインが開始し、現在のコミットにパイプライン実行IDのタグを付ける。

2. パイプラインはそのタグから対応する環境ブランチの内容を読み取ります。

3. パイプラインは、現在のコミットと <target-environment>_latest タグに関連付けられたコミットとの間のデプロイメントデルタを計算する。

4. パイプラインは差分（デルタ）を評価します：

   • デルタが空の場合、パイプラインは停止し、デプロイメントは発生しません。
   • デルタに変更が含まれている場合、パイプラインは継続する。

5. パイプラインはデルタで特定された変更を展開します。

6. デプロイが成功すると、パイプラインは新しいコミットに タグ <target-environment>_latest を付与します。

強制行動（フォース再配置付き）

が に設定されている force-redeploy``true 場合、パイプラインはデルタ検証をバイパスし、検出された変更の有無にかかわらず、完全なインベントリを再デプロイします。 このアプローチにより、アプリケーションの状態全体がデプロイ先に対して再適用されることが保証されます。

1. CDパイプラインが開始し、現在のコミットにパイプライン実行IDのタグを付ける。
2. パイプラインはそのタグから対応する環境ブランチの内容を読み取ります。
3. パイプラインはデプロイメント差分を計算しますが、このシナリオでは通常空です。
4. この force-redeploy=true 設定により、パイプラインは差分チェックをスキップして処理を続行します。
5. パイプラインはブランチからアプリケーション状態全体を再デプロイします。
6. 再デプロイが成功すると、パイプラインは直前にデプロイしたコミットにタグ <target-environment>_latest を付与します。

ロールバック・パイプラインの概要

このパイプラインでは、特定の ServiceNow 変更要求ID（例： CHG-12345）を指定することで、以前の正常な構成にロールバックできます。

この変更要求IDは、正常なデプロイメントの固有のブックマークとして機能し、ロールバックパイプラインに必要な入力項目です。

以前のデプロイメントの変更要求IDは、次の2つの方法で確認できます：

• ServiceNow: 復元したいデプロイメントの変更リクエストを検索してください。
• インベントリリポジトリ ：インベントリの状態はソース管理で管理されるため、各デプロイメントはコミットによって一意に識別されます。 元に戻したいコミットを見つけ、そのコミットに関連付けられたタグ CHG-*** を特定できます。

ロールバックパイプラインには以下の段階が含まれます：

• prod-rollback-start
• prod-setup
• prod-rollback-change-request
• prod-deployment
• prod-acceptance-tests
• prod-rollback-finish

パイプラインの実行は、環境 rollback-change-request-id プロパティの情報を使用して新しい変更要求を作成します。

コンプライアンスを維持するため、パイプラインは前回のデプロイに関連する問題を再オープンします。 これらの課題は新しい変更要求に添付されており、元の期限は変更されていません。 ロールバックが成功すると、インベントリ内のタグ _latest が前のコミットに移動します。

ロールバック パイプラインを作成する

を実行して cd-rollback-listener 、最後に正常と確認されたバージョンへのロールバックをトリガーします。

1. CDパイプラインに移動してください。
2. 手動トリガーを追加するか、 手動CDトリガー を複製してください。
3. トリガーを編集し、リスナーを に設定します cd-rollback-listener。
4. **「保存」**を選択します。
5. 必要な各リージョンとターゲット環境の組み合わせごとに、個別のトリガーを作成してください。

ロールバック パイプラインをトリガーする

ロールバック パイプラインの実行では、次の環境プロパティが使用されます:

以下の条件を満たさない限り、パイプラインは終了する：

• rollback-change-request-id 同じリージョンおよびターゲット環境に対する完了済みデプロイメントのIDでなければなりません。
• 関連するデプロイメントは、rollback-limit で指定 rollback-change-request-id されたデプロイメント数を超えて古いものであってはならない。

Tektonの環境 PIPELINE_NAME プロパティは、実行がデプロイメントかロールバックかを決定します。

• cd-rollback-pipeline ロールバックのデフォルト値。
• cd-pipeline デプロイメントのデフォルト値。

このプロパティを使用して分岐ロジックをカスタマイズできます。

ロールバックの概要 GitOps

継続的デプロイメント パイプラインを使用して、変更を特定のバージョンにロールバックする操作 Git を実行し、以前の commit-id バージョンのインベントリをターゲット環境にデプロイします。

変更 ServiceNow 要求IDでロールバックパイプラインをトリガーする代わりに、インベントリリポジトリ内で直接コミットを元に戻しているため、このプロセスでは以前のコンプライアンス問題が自動的に再開されたり、その期限が管理されたりすることはありません。

CDパイプラインがトリガーされると、再デプロイのために以下のステップを完了します：

• パイプラインが開始し、現在のコミット（差し戻しコミット）にパイプラインの実行IDをタグ付けします。
• パイプラインはそのタグから対応する環境ブランチの内容を読み取ります。
• パイプラインは、現在のコミットと <target-environment>_latest タグに関連付けられたコミットとの間のデプロイメントデルタを計算する。
• デプロイが成功した後、タグ <target-environment>_latest は新しい（元に戻された）コミットに移動されます。

ロールバックプロモーションのプルリクエストを作成する

1. ロールバックしたいデプロイメントバージョンのインベントリ内の commit-id IDを特定してください。
2. リポジトリの状態をそのコミットの状態に戻す。
3. 元に戻した状態を反映させるプルリクエストを作成する。

以下の例は、コマンド git を使用してこのシナリオを示しています。

1. コミットとタグを一覧表示し、最終的に正常な状態だったコミットIDを検索する（例： refs/tags/8）

   # /c/usr/devsecops/compliance-inventory (master)
   $ git show-ref --tags
   ...
   83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8 refs/tags/8
   ...
   1914a125e76aa97c497f4bd2c2f455b58cf079b8 refs/tags/prod_latest
   

2. 現在の状態 (refs/tags/prod_latest) と目標状態 (refs/tags/8) の間のすべてのコミットを一覧表示する。

   # /c/usr/devsecops/compliance-inventory (master)
   $ git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   67cc8babdff3e09c1f0e632f897798c1b5424f38
   6fab5ce3d60590cd858206424ecfd7d3a8c9ceb4
   ...
   

3. インベントリの状態をターゲットコミット（refs/tags/8）にロールバックする。

   # /c/usr/devsecops/compliance-inventory (master)
   $ git revert -n $(git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8)
   

4. 新しい状態をコミットする。

   # /c/usr/devsecops/compliance-inventory (master|REVERTING)
   $ git commit -m "revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8"
   [master af82538] revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   

5. 更新をマスターブランチにプッシュする。

   # /c/usr/devsecops/compliance-inventory (master)
   $ git push --set-upstream origin master
   ...
   To [https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git](https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git)
     67cc8ba..af82538  master -> master
   ...
   

継続的デプロイメントパイプラインをトリガーする

1. ロールバックプロモーションの変更に対するプルリクエストを作成してください。

2. プルリクエストをレビューし、マージする。

3. CDツールチェーンで手動CD パイプラインの実行をトリガーします。

インラインロールバックの概要

このモードは、同じパイプライン実行のコンテキスト内で現在のデプロイをロールバックします。 デプロイメントまたは受入テストの段階でエラーまたは障害が発生し、デプロイメントの試行が失敗としてマークされる場合に必要です。

環境 rollback-enabled プロパティが に設定されており、デプロイメント 1 または受入テスト段階で障害が発生した場合、インラインロールバックが自動的に実行されます。

ロールバックがトリガーされた場合、CDパイプラインは設定 .pipeline-config.yaml``rollback ファイルで定義されたセグメントを実行します。 ファイルにセグメント rollback が定義されていない場合、デフォルトの実装が実行され、ロールバックスクリプトの提供を促します。

ロールバックスクリプトの例 .pipeline-config.yaml：

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

インラインロールバック中に設定されるプロパティ

• rollback-status ロールバックステップのステータスを示します。 考えられる値： [notRun, success, failure]
• rollback-exit-code ロールバックステップの終了コード。 ロールバックが実行されなかった場合、この値は空になります。
• default-rollback-executed デフォルトの実装（スクリプトの入力を促すもの）が実行された場合に true 設定する。 この値はデフォルトでは空である。
• pipeline-execution-status: パイプライン全体の実行状態を示します。 考えられる値： [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]