自動化された変更管理

変更管理の自動化は、DevSecOpsパイプラインの参照実装の重要な部分である。 開発者、承認者、監査人は、デプロイのコンプライアンス面を監視できる。 すべての配備は、組織の変更管理ポリシーに従わなければならない。

パイプラインは、ビルドおよびデプロイメントの各ライフサイクル部分からエビデンスを収集します。 すべての証拠は、成果物の特定のビルドと配備に関連している。 したがって、デプロイされた成果物ごとに、そのビルド・デプロイメントまたはテスト・デプロイメントにインシデントがあるかどうかを判別できます。 この相関分析は、インベントリー・モデルによって実装されます。

エビデンス、インベントリー、チェンジ・マネジメントの関係

図1は、エビデンス、インベントリ、変更管理の間のデータの流れとつながりを示している。

エビデンス、インベントリー、変更管理間のつながり
エビデンス、インベントリー、変更管理間のつながり

  1. CIはビルド・アーティファクトを実行し、それらのアーティファクトの作成中に何が起こったかの証拠を残す。
  2. CI の実行により、作成された成果物に関する項目がインベントリーに作成されます。
  3. インベントリー内のビルド成果物はデプロイメント環境 (ステージングや実動前など) に プロモートされます。
  4. 変更管理の自動化は、インベントリ、エビデンスロッカー、およびプロモーションPRからのデータを使用して、変更要求のデプロイメントを作成します。 また、変更管理オートマトンは、例えば受け入れテストの証拠を残します。 デプロイとテストに成功した成果物は、さらに本番環境に昇格する。

すべての環境と地域への配備は、変更管理システムに変更要求を提出しなければならない。 変更管理の自動化では、パイプラインから収集されたすべてのエビデンスと情報に基づいて、これらの変更要求を作成できるようになります。

詳しくは、 変更管理の自動化 を参照してください。

変更管理コマンドの順序

変更要求ステップの順序は、以下のとおりです。

変更要求の作成

ベースラインを変更するものはすべて、変更要求を使って追跡しなければならない。 変更には、例えば、既存のコードレベルの更新、コンフィギュレーションの変更、ワーカーノードの更新などが含まれる。 ピアレビュー遵守データの収集は、インベントリ、証拠品ロッカー、インシデント・イシュー・リポジトリでアクセス可能なデータに基づいて行われる。

最後に、このステップでは、「プロモーション PR」フィールドに基づいて変更要求を作成し、使用可能なコンプライアンス・データを添付します。 デプロイメントの準備状況は、使用可能なエビデンスに基づいて、収集されたコンプライアンス状況によって計算されます。

承認の要求

作成された変更要求のデプロイメント状態が「準備完了」でない場合、このステップは変更の承認を要求します。

承認の確認

すべてのコンプライアンスチェック(ユニットテスト、CRAタスク、ブランチ保護、秘密の検出など)が成功すれば、変更要求は自動的に承認され、タスクは正常に実行される。

コンプライアンス検査が失敗すると、変更要求状態は承認されません。

手動で変更リクエストを承認し、change-request-id を環境プロパティに追加することで、次回の実行で既に作成された変更リクエストを使用することができます。

もう 1 つの解決策は、プロモーション・プル要求で emergency ラベルを使用することです。 詳しくは、 緊急ラベルの追加 を参照してください。

次に設定 implement

このステップでは、変更の success または failure 状況に応じて、変更要求の状況を implement に設定します。

変更依頼を閉じる

デプロイメントに関する詳細がクローズ・サマリー変更タスクにアップロードされ、変更要求がクローズされます。 変更依頼のクローズ・タスクでは、close_category が以下の値で追加されます。

  • successful
  • successful with issues(要約に問題がある場合)