派遣前準備評価

変更要求が作成される前に、パイプラインは Deployment Readinessを計算し、 DEPLOYMENT_READY フラグを true または false に設定します。 このフラッグは、CIとCDの各段階で収集されたエビデンスから導き出されたものである。 いずれかのエビデンスチェックが、配備されたアーティファクトセットに関連する逸脱、またはチェック、スキャン、またはテストの欠落や失敗を示す場合、 DEPLOYMENT_READY は、 false に設定される。

変更要求は、最後にマージされたプロモーションPRからターゲットブランチへの以下のフィールドをソースとして作成されます：

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

変更要求の作成

準備された変更要求は、 DEPLOYMENT_READY に応じて2つの初期状態のいずれかで提出される：

また、変更管理システムは、実装によってダウンタイムが発生せず（停止期間がゼロ）、 DEPLOYMENT_READY 、 true、展開リスクが許容範囲内にある場合に、変更要求を自動的に承認する。

変更で計画休止時間が必要な場合は、変更要求を手動で作成し、承認のために送信する必要があります。 それが承認されると、変更要求 ID を指定してデプロイメントを開始することができます。 パイプラインは承認状態をチェックし、デプロイメントを実行する。 詳しくは、 変更依頼の手動承認 を参照してください。

配備前の添付書類

変更要求が作成された直後、パイプラインはCRレコードに以下の成果物を添付する：

• 配置 BOM- 配置に含まれるすべてのコンポーネントをリストします
• Delta Summary- 配備に参加しているすべてのコンポーネントの証拠態勢
• エビデンスチェック設定ファイル- 必要なエビデンスチェックに基づくゲーティングがパイプラインで設定されている場合にのみ添付される
• SCCプロファイル- セキュリティとコンプライアンス構成が設定されている場合のみ添付される

承認ゲート

変更要求が未承認として作成された場合、その要求は未承認の状態に置かれ、人間によるレビューのために送られる。 承認が下りるまで配備は行われない。

パイプラインのログから作成された変更リクエストIDを確認し、承認を待ってから、その同じ変更リクエストIDを使用してデプロイを再開できます。 パイプラインは承認状態をチェックし、デプロイを続行する。

デプロイメントと受け入れテスト

CRがインプリメントされた状態で、パイプラインが実行される：

• CDデプロイメント- ターゲット環境にコードをプロモートする
• 受け入れテスト- 配備結果を検証する

この2つはユーザー主導のランステージだ。

配備後のCR閉鎖

デプロイメントテストと受け入れテストが合格すると、パイプラインはクロージングアーティファクトをアタッチし、変更リクエストをクローズする：

• クロージングサマリー- ターゲットコミットレベルの全インベントリエントリーの証 拠のサマリー。
• マージされたSBOM- インベントリ内のすべてのコンポーネントにわたる展開後のソフトウェア部品表。

その後、CRはクローズ時の DEPLOYMENT_READY に基づいて close_category でクローズされる：

変更のタイプ

変更要求管理では、 緊急変更と通常変更の2種類の変更に対応しています。

今回の変更が緊急の変更である場合は、プロモーション用プルリクエストに「 emergency 」ラベルを追加してください。

CIパイプライン側には緊急フローはない。 ただし、CI パイプライン/トリガー・プロパティ skip-inventory-update-on-failure を空の値または 0 に設定すると、CI パイプラインの実行で問題が検出された場合でも、インベントリ・リポジトリを更新できます。 この更新されたインベントリーがあれば、緊急変更が可能になる。

リカバリーの道を選ぶ

パス1：専用のロールバック・リスナーを使用したフル・ロールバック

Last-known-good コンフィギュレーションが存在する場合、つまり、以前にデプロイされた状態で安定が確認されている場合、サービス復旧への最速のパスは完全なロールバックである。 これは、このシナリオのために作られた専用のロールバック・リスナーを使用するもので、新規構築や昇格を必要としない。

ステップバイステップの手順と構成するパラメータについては、 専用のロールバック・リスナーを使用した完全ロールバックを 参照してください。

パス2：緊急変更としてのフィックス・フォワード

実行可能なロールバックターゲットが存在しない場合、あるいはすでに調査によってパッチが作成されている場合、その修正は緊急の変更として配備することができる。 この経路は、標準的なエビデンスゲーティングロジックを短絡させる。パイプラインは、変更を即座に実装することを可能にし、変更要求は、インシデントが解決された後、遡及的なレビューと承認の対象となる。

この方法を使うということは、本番環境にデプロイされたコードに、未解決の脆弱性や未解決の証拠ギャップが残っている可能性があることを受け入れるということだ。 サービス復旧の方が優先され、未解決のコンプライアンス項目は、インシデント終了後に対処されなければならない。

この2つの道は互いに排他的なものではない。 実際には、まず完全なロールバックを開始してサービスを直ちに復旧させ、パッチの準備が整い、検証された時点でフィックス・フォワードでフォローアップすることもある。 シーケンシングは、その時の状況に応じてオペレーターの判断に委ねられる。

フィックス・フォワードの手順

CIE中に緊急変更として修正を適用するには、以下の手順に従ってください：

1. 影響を受けたコンポーネントを再構築する。 CIパイプラインを実行して、修正を含む新しいアーティファクト・バージョンをビルドする。 CIエビデンスチェックがインシデント条件により失敗している場合、パイプラインまたはトリガプロパティ skip-inventory-update-on-failure 、失敗にもかかわらずインベントリが更新されるように、空の値または 0 、緊急変更を続行できるように設定する。

2. 環境を通じて修正を促進する。 最も低い環境から開始し、プロダクションに向けてプルリクエストを昇格させる。 時間が許せば、各段階で修正点を確認してから、さらに推進する。 状況が危機的な場合は、直接本番稼動に移行し、サービス復旧後に下位環境を調整する。

3. 緊急ラベルを貼る。 本番をターゲットとしたプロモーションのプルリクエストに、 emergency ラベルを追加する。 これは、標準的なエビデンス・ゲーティングをバイパスし、その変更を緊急配備として扱うべきであることをパイプラインに知らせるものである。

4. プロダクションにデプロイする。 CDパイプラインを実行する。 パイプラインは緊急ラベルを検出し、承認待ちをスキップして、直ちに配備と受け入れテストに進む。 変更要求が作成され、 close_category = successful with issues でクローズされる。これは、変更が緊急状況下で展開されたことを反映している。

5. 下位の環境を調整する。 本番環境でのインシデントが解決したら、同じ緊急修正アーティファクトを下位環境（ステージング、プリプロダクションなど）に展開し、すべての環境が本番環境と一貫した状態になるようにします。 本番環境に昇格する前に下位環境を検証した場合は、すべての階層で同じアーティファクト・バージョンが使用されていることを確認する。

CIE後の義務

緊急配備には、事故が収束した後に対処しなければならないコンプライアンス義務が発生する：

• 変更要求は、適切な承認者によって遡及的にレビューされ、承認されなければならない。
• 未解決の脆弱性、不完全なスキャン、チェックの失敗など、緊急時に認められた証拠のギャップはすべて修正し、パイプラインを標準的な条件で再実行しなければならない。
• 根本原因分析（RCA）を実施し、文書化すべきである。

パイプラインによって添付されたデルタサマリー、クロージングサマリー、およびマージされたSBOMを含む変更要求レコードは、CIE後のレビューの主要な監査証跡として機能する。

緊急時の流れを呼び起こす

緊急時のフローはユーザー主導である：

1. ユーザーは、 emergency ラベルをプロモーションのプルリクエストに適用してパイプラインを実行します。
2. パイプラインは緊急指定を検出し、配備と受入テストは標準の承認を待つことなく直ちに進められる。
3. このCRは、クロージング・ノート（ successful with issues ）をもって終了する。

今回の変更が緊急の変更である場合は、パイプラインを実行する前に、プロモーション用プルリクエストに「 emergency 」ラベルを追加してください。

緊急事態後の展開

緊急フローが配備とテストを完了すると、配備後の段階で標準フローに復帰する：

• クロージングサマリーと統合SBOMはCRに添付されている。
• CRは、標準的なフローと同じ DEPLOYMENT_READY-based close_category ロジックに従ってクローズされる。

CR タイプが emergency の場合、変更要求は配備後に遡ってレビューされ、承認されなければならない。

トリガー条件

インライン・ロールバック・フローは、デプロイメント・テストや受け入れテストが合格しなかった場合に入る。 次にパイプラインは、インライン・ロールバックが有効かどうかを評価する：

• インライン・ロールバックが有効になっていない ：CRは close_category = unsuccessful 、パイプラインは終了する。 自動回復は試みられない。
• ロールバックが有効 ：ロールバックスクリプトが実行されてターゲット環境が戻され、ロールバックの成果物が収集されてCRに添付される。

インライン・ロールバックの実行

インライン・ロールバックが有効な場合、パイプライン：

1. CD パイプラインでデプロイメントまたは受け入れテストが失敗した場合、インライン ロールバック スクリプトを実行します。
2. 以下の成果物を収集する：
   • ロールバックログ- ロールバックスクリプト実行時の出力
   • クロージングサマリー- ロールバックの結果を反映
   • マージされたSBOM- ロールバック後のソフトウェア部品表
3. オープンCRレコードに3つの成果物すべてを添付する。

ロールバック後のCR閉鎖

インラインロールバックとアーティファクトのアタッチメントの後、CRは close_category = unsuccessful でオープンなままとなる。 これは、展開が試みられ、失敗し、自動的に元に戻されたことを変更管理に知らせるものである。

close_category = unsuccessful のCRは、配備が逆転したときに予想される正しい結果であり、プロセスの失敗を示すものではない。 運用チームは、添付のロールバックログを使用して根本原因を調査する必要があります。

事前に承認された変更要求によるパイプラインの実行

デプロイメントには、事前に承認された変更要求（CR）を使用できます。 つのシナリオが考えられる：

CDパイプラインが以前のCDパイプラインの実行によって作成されたCRを認識すると、ファストパスによってデプロイメントを実行します：

• CR証拠から事前計算された差分と証拠要約を再利用する。
• ピアレビューと署名検証の手順を省略する。
• 事前計算された差分を展開中。

CDパイプラインが、CRが以前のCDパイプラインの実行によって作成されたかどうかを判断できない場合または、提供されたCRが現在のランのデプロイメントターゲットと一致しない：

• 事前計算されたデルタや証拠の要約を一切再利用しません。
• 査読や成果物の署名検証を省略することはない。
• デルタとサマリーをゼロから計算し直す。
• CRはすでに供給されているため、新しいCRは作成されない。

失敗したデプロイメントに対するパイプラインの再実行

自動変更管理機能を利用したくない場合は、事前に作成・承認済みの変更依頼書を提出することも可能です。 以下のシナリオで失敗したデプロイメントを再実行します。

• 自動的に作成された最新の変更リクエストは、デプロイの準備が整っておらず、自動承認もされていません。 承認を受けたので、同じ変更要求を使用して配備を再開する必要があります。
• デプロイメントにダウン時間が必要です。 変更依頼を作成し、承認を得て、組織の変更管理ポリシーに従いました。
• コードや構成の変更はありませんでした。 あなたは変更要求を作成し、変更内容を説明し、承認を受け、承認された変更要求を使って配備を開始しました。

変更要求(CR)はCDパイプラインが完了した後もオープンなままである。

事前に承認済みの変更リクエストを使用し、**change-request-id** プロパティに変更リクエスト ID を入力することで、 DevSecOps のリファレンス継続的デプロイメントパイプラインを開始できます。

change-request-id プロパティが設定されている場合、パイプラインはその変更リクエストのデータ収集をスキップし、承認状態の確認に進みます。 「change-request-id」 がデフォルトで「 notAvailable 」に設定されている場合、パイプラインによって変更リクエストが自動的に作成されます。