プロモーション・パイプライン

プロモーション・パイプラインは、ある環境から別の環境へインベントリエントリを移行し、プロモーションのプル/マージリクエストを作成します。

昇進時の職務分掌

  • 主にプルリクエストのワークフロー を通じて達成されたプロモーション

    • → プロモーションPRを作成する(例:ソース環境からターゲット環境のブランチへ)
    • → PRの確認・編集(PRの検証ステータスの確認を含む)
    • → PRをターゲット環境のブランチにマージする
    • → CDデプロイメントパイプラインを実行する(コミット時、タイマー、または手動でのトリガー)
    • → 次の環境ブランチについても、同じ手順を繰り返します
    • → 環境ブランチは任意の数だけ作成可能です
  • 役割

    • 開発者 :コードをコミットすると、CIパイプラインによってメイン(本番環境以外)のインベントリが更新される
    • プロモーション運用/リリースマネージャー :プロモーションパイプライン(メイン→ステージングおよび/またはステージング→本番)を起動し、ゲートチェックのためのステータス確認を含むプルリクエスト(PR)を作成する(ツールチェーンのACLおよびインベントリブランチの保護機能によって強制される)
    • 運用チーム/承認者 :プロモーション用プルリクエストを確認し、prodブランチにマージしてください。 本番パイプラインを実行する。(インベントリブランチ保護によって強制される)
  • ステージング環境と本番環境向けのそれぞれ異なるCDツールチェーン のワークロードを活用する(個別の運用)

  • つまり、開発者は変更内容を準備することはできますが、ブランチ保護の設定により別途承認者が必要とされる場合、一方的に本番環境にデプロイすることはできません。

  • プロモーションPRが、変更承認の正式な記録となる、およびマージ履歴には、本番環境への昇格を誰がいつ承認したかという、監査可能な証拠が記録されています。

プロモーション・パイプラインのステップ

  1. プロモーションおよびプロモーションのプルリクエスト/マージリクエストに関する意見や提案を募集します。
  2. ソース環境からターゲット環境にインベントリー・エントリーをプロモートします。
  3. プロモーションのプルリクエストまたはマージリクエストを作成してください。 プル/マージ要求を編集して、実行する変更を指定します。 オプション・フィールドおよび必須フィールドに注意してください。
  4. オプション。 エビデンス状況を設定し、集約されたエビデンス要約をプロモーションのプル/マージ要求に追加します。
  5. プル/マージ要求をマージします。
  6. この機能が有効になっている場合は、Slackに通知を送信します。

ステージとタスク

次の表は、プロモーション・パイプラインで実行されるタスクの一覧です。 さらに、この表には、これらの各段階の概要も示されています:

  • タスクまたはステージ :これは、 .pipeline-config.yaml の設定ファイル内で定義されているステージの名前を指します。

  • 概要 :ここでは、このステージの実行中に実行されるアクションについて簡潔に説明します。

  • カスタマイズ可能 :これは、ユーザーが .pipeline-config.yaml ファイルにカスタムスクリプトを挿入することで、ステージのデフォルトの動作を変更または置き換えることができるかどうかを示します。

  • デフォルトのリファレンス実装 :これは、 DevSecOps のパイプラインに、そのステージ用の事前定義済みまたはデフォルトの実装が含まれているかどうかを示します。 特に、 unit-testssetup といった特定のステージについては、 DevSecOps のパイプラインでは、そのまま利用できる実装は提供されていません。 その代わりに、ユーザーは、自身のアプリケーションの要件に合わせてカスタマイズしたスクリプトやコードを用意する必要があります。

  • 証拠の収集 :この項目は、当該段階において標準的な証拠の収集が行われるかどうかを示しています。 DevSecOps Pipelineがステージの参照実装を提供する場合、証拠の収集はそのままの状態で実行されます。 ただし、ユーザーがこれらの事前定義された段階を変更または置き換えることを選択した場合は、独自の実装に適切な証拠収集が含まれていることを確認する必要があります。 DevSecOps パイプラインが既成の実装を提供していない段階については、ユーザーにも同様の責任が課せられ、証拠の収集を行う必要があります。 この列は、証拠収集の実施を担当するエンティティ( ユーザー/パイプライン )を示しています。

  • スキップの許可(バージョン v10 以降に適用) :これは、 .pipeline-config.yaml 内で skip プロパティを true に設定することで、ユーザーがこのステージの実行をスキップできるかどうかを示します。 ただし、この機能を使用する際には、特に証拠収集を目的としたステージでは、注意が必要です。 こうした段階を省略すると、ビルドに不可欠な証拠を見逃すことになりかねません。

プロモーションのパイプラインの各段階とタスク
タスクまたはステージ 簡略説明 以下の項目についてはカスタマイズが可能です .pipeline-config.yaml デフォルトのリファレンス実装 エビデンスの収集 スキップ可能
inventory-promotion このプロモーションについてプルリクエストを作成してください。 いいえ ある NA いいえ
inventory-finish ログ・ファイル、成果物、エビデンスを収集し、エビデンス・ロッカーにアップロードします。 ある いいえ NA いいえ

.pipeline-config.yaml ファイルを使用してステージをカスタマイズする方法の詳細については、「 カスタムスクリプト 」および「 パイプラインパラメータ の一覧」を参照してください。

プロモーション・パイプラインの実行

プロモーション・パイプラインを実行するには、手動プロモーション・トリガーを使用します。 ソース(master)ブランチがターゲット(prod)ブランチよりも進んでいる場合、パイプラインはプロモーション用のプルリクエストまたはマージリクエストを作成します。これらは確認や編集が可能です。 ソース・ブランチがターゲットより遅れている場合は、プロモーション・パイプラインは失敗して All changes have already been promoted というメッセージが表示されます。

プロモーションのプルリクエストまたはマージリクエストのデフォルト値を変更する場合、あるいは別のソースからターゲットへプロモーションを行う場合、ユーザーは「パイプライン環境変数」UIから 入力内容を 変更できます。

継続的デプロイメントパイプラインを実行する前に、プロモーション用のプルリクエストまたはマージリクエストがマージされていることを確認してください。 プルリクエスト/マージリクエストは URL パイプラインログで確認できます。

インベントリーとプロモーション・プロセスについて詳しくは、インベントリーのプロモーションを参照してください。

在庫品を部分的に宣伝する

部分的なプロモーション方法を使用すると、プロモーション パイプラインで利用可能な在庫の選択したサブセットをプロモーションできます。

この文脈における「インベントリエントリ」とは、インベントリリポジトリ内に存在する(インベントリタイプの)単一のファイルを指し、これはローカルファイルシステム上の固有のファイル名に対応します。

パラメータの使用 inventory-include そして inventory-exclude 部分的なプロモーション方法を有効にします。

使用する場合 inventory-include 環境プロパティで提供されるパターン/ファイル名は、それぞれのエントリに解決され、パイプラインによって昇格されます。 同様に、inventory-exclude 昇進から除外されます。

このフォーマットは、CC パイプラインで採用されているものと同様に、glob パターン (フルパスもサポート) を使用します。 globパターンの詳細については、グロブマニュアル。

部分的なプロモーションに適用されるフィルタリング

部分的なプロモーションでは、2つのレベルのフィルタリングが適用されます。.inventoryignore ファイルと与えられたglobパターンに基づいてフィルタリングを適用します inventory-include そして inventory-exclude

.inventoryignore ファイルの使用

部分的なプロモーション実行やCDパイプライン実行で、デフォルトでファイルやフォルダのセットを除外するには、ファイル/フォルダのリストを .inventoryignore これらのエントリを除外するファイル。

利用可能なエントリ(パイプラインが昇格できるもの)のリストは、.inventoryignore ファイル。

パイプラインは、.inventoryignore リポジトリのルートにあるファイル。 インベントリ除外ファイルに別の名前を使用する場合は、inventory-ignore-file パイプライン内の環境プロパティとしてキーを使用します。 このファイルがインベントリ リポジトリのルートにあることを確認してください。

inventory-includeパラメータの使用

提供されたエントリーをフィルタリングした後、宣伝するエントリーのリスト inventory-include および/または inventory-exclude

両方 inventory-include そして inventory-exclude 存在しています、inventory-include 優先され、その後 inventory-exclude 包含リストによって定義されたサブセットから項目を除外します。

これらの変数のいずれかが指定されている場合、パイプラインは glob パターンの完全なパスを解決しようとするか、ファイル名を直接解決して部分的なプロモーションを続行します。

2 つのフィルタリング レベル間の共通エントリ リストのみがパイプラインによって昇格されます。

inventory-include および inventory-exclude パラメータの使用例

このセクションでは、グロブパターンの使用例と、それを inventory-include そして inventory-exclude パラメーター。 以下は、マイクロサービス、(ネストされた) 構成ファイル、および Helm チャートを含むインベントリ リポジトリのディレクトリ構造の例です。

cd-pipeline-deps
my-application-plugin-component-config
my-application-plugin-component-diagnostic-monitor
configuration # directory entry
configuration/my-staging-region # directory entry
configuration/my-staging-region/environment-1-cluster # directory entry
configuration/my-staging-region/environment-1-cluster/serviceA-component_config
configuration/my-staging-region/environment-1-cluster/serviceB-system_config
configuration/my-staging-region/environment-1-cluster/serviceC-params_config
configuration/serviceX-dashboard-setup_helm
configuration/serviceY-releases_helm
my-application-task-runner
my-application-dashboard
my-application-dashboard_deployment
my-application-module
my-application-module_deployment
.inventoryignore
global_deployment
README.md

コンポーネントのすべてのサブモジュールエントリを選択するには

inventory-include に設定 :*plugin-component*

選択された在庫エントリ:

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor

特定の構成フォルダ内のすべてのHelmチャートを選択するには

inventory-include に設定 :configuration/*helm

選択された在庫エントリ:

    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

特定の環境のすべての設定ファイルを選択するには

inventory-include に設定 :configuration/my-staging-region/environment-1-cluster/*_config

選択された在庫エントリ:

    configuration/my-staging-region/environment-1-cluster/serviceA-component_config
    configuration/my-staging-region/environment-1-cluster/serviceB-system_config
    configuration/my-staging-region/environment-1-cluster/serviceC-params_config

1つのコンポーネントのみを選択するには

inventory-include に設定 :my-application-dashboard*

選択された在庫エントリ:

    my-application-dashboard
    my-application-dashboard_deployment

inventory-include で glob パターンの組み合わせを使用する

inventory-include に設定 :*plugin-component*,configuration/*helm

選択された在庫エントリ:

    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    configuration/serviceX-dashboard-setup_helm
    configuration/serviceY-releases_helm

inventory-exclude で glob パターンの組み合わせを使用する

inventory-exclude に設定 :configuration/**, my-application-dashboard*

選択された在庫エントリ:

    cd-pipeline-deps
    my-application-plugin-component-config
    my-application-plugin-component-diagnostic-monitor
    my-application-task-runner
    my-application-module
    my-application-module_deployment
    .inventoryignore
    global_deployment

プロモーションのプル/マージ要求

プロモーションのプルリクエスト/マージリクエストの本文に含まれる情報は、変更リクエストの作成に使用されます。 プロモーションのプルリクエストまたはマージリクエストによって変更されたファイルは、継続的デプロイメントパイプラインによってデプロイされるエントリ(画像など)を表しています。 変更が緊急事態のために実施された場合、そのプルリクエストまたはマージリクエストには「緊急」ラベルが付けられます。 継続的デプロイメントパイプラインによって作成された変更リクエストも、 emergency としてマークされます。

継続的統合パイプラインで収集された証拠は要約され、継続的デプロイメント・パイプラインの変更要求に付加されます。

プロモーション検証パイプライン

プロモーション PR を開くと、オプションで、プロモーション検証パイプラインでエビデンス集約およびサマリー生成を実行し、プロモーション・プル/マージ要求 (PR) でエビデンス・ステータスを設定できます。 PR は、プロモーション・パイプラインによって作成することも、在庫リポジトリーで手動で作成することもできます。

このパイプラインにより、PR がターゲット・ブランチ (環境) にマージされる前に、プロモーション PR の早期検証が可能になります。 PR のステータスに基づいて、ユーザーはプロモーションを続行するか (すべてのエビデンス・ステータスが緑の場合)、継続的な統合パイプラインで問題を修正するか (エビデンス・ステータスが赤の場合) を選択できます。

さらに、検証パイプラインは、インベントリ内の1つ以上のアプリケーションに関する証拠の集計サマリーを、ユーザーフレンドリーな表形式(図3に示す通り)で、昇格プル/マージリクエストへのコメントとして追加します。 この表には、各アプリケーション向けに作成されたパイプラインの実行、アプリリポジトリ、および課題へのリンクなど、有用なリンクが提供されています。

デフォルトでは、 詳細な証拠ステータス表の各行は、インベントリエントリで参照されるアーティファクトの作成に使用されるソースリポジトリによって提供されるアプリケーションコンテキストに対応します。 このアプリケーションのデフォルトのグループ化は、各インベントリエントリファイルに対して(プロパティで定義された application-group-by-filter)JSONフィルターを適用して得られるグループ化値に基づいてカスタマイズできます。

検証の進行中は、プロモーションのプル/マージ要求のマージはブロックされます。 検証パイプラインが完了すると、証拠状況がプル/マージ要求で設定されます。 ステータスの各エントリーをクリックすると、対応する CI パイプライン実行の特定のステージに移動します。

ステージとタスク

次の表は、プロモーション検証パイプラインで実行されるタスクの一覧です。 さらに、この表には、これらの各段階の概要も示されています:

  • タスクまたはステージ :これは、 .pipeline-config.yaml の設定ファイル内で定義されているステージの名前を指します。

  • 概要 :ここでは、このステージの実行中に実行されるアクションについて簡潔に説明します。

  • カスタマイズ可能 :これは、ユーザーが .pipeline-config.yaml ファイルにカスタムスクリプトを挿入することで、ステージのデフォルトの動作を変更または置き換えることができるかどうかを示します。

  • デフォルトのリファレンス実装 :これは、 DevSecOps のパイプラインに、そのステージ用の事前定義済みまたはデフォルトの実装が含まれているかどうかを示します。 特に、 unit-testssetup といった特定のステージについては、 DevSecOps のパイプラインでは、そのまま利用できる実装は提供されていません。 その代わりに、ユーザーは、自身のアプリケーションの要件に合わせてカスタマイズしたスクリプトやコードを用意する必要があります。

  • 証拠の収集 :この項目は、当該段階において標準的な証拠の収集が行われるかどうかを示しています。 DevSecOps Pipelineがステージの参照実装を提供する場合、証拠の収集はそのままの状態で実行されます。 ただし、ユーザーがこれらの事前定義された段階を変更または置き換えることを選択した場合は、独自の実装に適切な証拠収集が含まれていることを確認する必要があります。 DevSecOps パイプラインが既成の実装を提供していない段階については、ユーザーにも同様の責任が課せられ、証拠の収集を行う必要があります。 この列は、証拠収集の実施を担当するエンティティ( ユーザー/パイプライン )を示しています。

  • スキップの許可(バージョン v10 以降に適用) :これは、 .pipeline-config.yaml 内で skip プロパティを true に設定することで、ユーザーがこのステージの実行をスキップできるかどうかを示します。 ただし、この機能を使用する際には、特に証拠収集を目的としたステージでは、注意が必要です。 こうした段階を省略すると、ビルドに不可欠な証拠を見逃すことになりかねません。

プロモーション検証パイプラインの各段階とタスク
タスクまたはステージ 簡略説明 以下の項目についてはカスタマイズが可能です .pipeline-config.yaml デフォルトのリファレンス実装 エビデンスの収集 スキップ可能
inventory-validation 昇格のために提出されたプルリクエストを承認します。 いいえ ある NA いいえ
validation-finish ログ・ファイル、成果物、エビデンスを収集し、エビデンス・ロッカーにアップロードします。 ある いいえ NA いいえ

.pipeline-config.yaml ファイルを使用してステージをカスタマイズする方法の詳細については、「 カスタムスクリプト 」および「 パイプラインパラメータ の一覧」を参照してください。

プロモーション検証にオプトインする方法

非推奨 プルリクエストのプロモーション検証パイプラインを自動的にキックオフするために使われていた opt-in-promotion-validation オプションは、 deprecated Git Promotion Validation trigger に取って代わられました。 環境設定にこのプロパティーがある場合は、パイプライン・ログと Slack 通知に非推奨の通知が表示されます。

プロモーション・バリデーションを有効にするには?

すべての新しいCDツールチェーンについて、「 Git 」のプロモーション検証トリガーが自動的に作成され、有効に設定されます。

既存のパイプラインで Git 販売促進検証トリガーを有効にするには、以下のステップを使用できます。

  1. 追加先となる CD パイプラインの 「トリガー」 ページに移動します。
  2. 新規トリガーを追加するには、 「追加」> Git 「リポジトリー」 を選択します。
  3. トリガーに必要な以下の情報を入力します。
    • トリガー名を指定してください。 例: Git Promotion Validation Trigger。
    • EventListener として promotion-validation-listener or promotion-validation-listener-gitlab を指定します。
    • リポジトリー 」フィールドで、パイプラインに対応するインベントリー・リポジトリーを選択します。
    • 「ブランチ」 のターゲット環境の名前を選択します。
    • 「プル要求のオープン時または更新時 (When a pull request is opened or updated)」 フィールドのボックスにチェック・マークを付けます。
  4. 追加 をクリックします。
  5. トリガーを 「オン」 に設定します。

入力

プロモーション・パイプラインの入力
変数 説明 デフォルト値 必須またはオプション
source-environment プロモーションのソース・インベントリー・ブランチ。 master 必須
target-environment プロモーションのターゲット・インベントリー・ブランチ。 prod 必須
優先 変更の優先度。 criticalhighmoderatelow、または planning オプション
assignee 変更要求 IBM Cloud 組織で、この変更要求を割り当てる機能 ID または個人の E メール。 '' オプション
説明 変更要求の説明に付加される変更の説明。 '' オプション
目的 変更が必要な理由。 '' オプション
impact この変更の実施がどのような影響を与えるかについて、さらに補足します。 '' オプション
インベントリ無視ファイル .inventoryignore ファイルのカスタム ファイル名。このファイルには、部分プロモーションの実行ごとに無視するファイル/フォルダーのリストが含まれています。 .inventoryignore オプション
在庫を含める 選択的にプロモーションする在庫エントリ(部分プロモーション)。 '' オプション
在庫除外 部分プロモーションで除外する在庫エントリ。 '' オプション
backout-plan 失敗した場合の変更のロールバック方法についての計画。 '' オプション
slack-notifications Slack 統合をオンまたはオフにするスイッチ。 0 オプション
顧客への影響 顧客に対する変更の影響。 criticalhighmoderatelow、または no_impact オプション

出力と結果

  • Slack 通知
  • プロモーションのプル/マージ要求

オプション・パラメーターが指定されていない場合は、プル/マージ要求を編集および変更する必要があります。

表 2.Optional パラメーター
変数 説明 必須またはオプション
優先順位 以下のいずれかの値: CriticalHighModerateLowPlanning 必須
変更要求の割り当て対象者 割り当て対象者の E メール ID。 必須
追加説明 アプリケーションの変更点に関する説明。 オプション
目的 アプリケーションに加えられた変更の目的。 オプション
影響の説明 アプリケーションの動作や環境の変更による影響。 オプション
顧客の影響 以下のいずれかの値: CriticalHighModerateLowNo_Impact 必須
デプロイメントの影響 以下のいずれかの値: SmallLarge 必須
バックアウト計画 デプロイメントが失敗した場合にバックアウトするステップ。 オプション

プロモーションプルとマージリクエスト
プロモーションプルとマージリクエスト

(オプションの) プロモーション PR 検証が実行されると、証拠状況がプル/マージ要求に設定されます。

昇格プルおよびマージ要求に設定されるオプションの証拠ステータス
昇格プルおよびマージ要求に設定される証拠ステータス

証拠 (インベントリー内の複数のアプリから得られる可能性がある) の集約された証拠要約が、PR 内のコメントとして表形式で表示されます。

プロモーションのプルおよびマージ依頼のコメントに含まれる、任意で集計されたエビデンスサマリー
プロモーションのプルおよびマージ依頼に含まれる、集計されたエビデンスサマリー

次のステップ

Promotion Pipeline が正常に終了したら、 CD パイプラインに進む ことができます。