プロモーション・パイプライン
プロモーション・パイプラインは、ある環境から別の環境へインベントリエントリを移行し、プロモーションのプル/マージリクエストを作成します。
昇進時の職務分掌
-
主にプルリクエストのワークフロー を通じて達成されたプロモーション
- → プロモーションPRを作成する(例:ソース環境からターゲット環境のブランチへ)
- → PRの確認・編集(PRの検証ステータスの確認を含む)
- → PRをターゲット環境のブランチにマージする
- → CDデプロイメントパイプラインを実行する(コミット時、タイマー、または手動でのトリガー)
- → 次の環境ブランチについても、同じ手順を繰り返します
- → 環境ブランチは任意の数だけ作成可能です
-
役割
- 開発者 :コードをコミットすると、CIパイプラインによってメイン(本番環境以外)のインベントリが更新される
- プロモーション運用/リリースマネージャー :プロモーションパイプライン(メイン→ステージングおよび/またはステージング→本番)を起動し、ゲートチェックのためのステータス確認を含むプルリクエスト(PR)を作成する(ツールチェーンのACLおよびインベントリブランチの保護機能によって強制される)
- 運用チーム/承認者 :プロモーション用プルリクエストを確認し、prodブランチにマージしてください。 本番パイプラインを実行する。(インベントリブランチ保護によって強制される)
-
ステージング環境と本番環境向けのそれぞれ異なるCDツールチェーン のワークロードを活用する(個別の運用)
-
つまり、開発者は変更内容を準備することはできますが、ブランチ保護の設定により別途承認者が必要とされる場合、一方的に本番環境にデプロイすることはできません。
-
プロモーションPRが、変更承認の正式な記録となる、およびマージ履歴には、本番環境への昇格を誰がいつ承認したかという、監査可能な証拠が記録されています。
プロモーション・パイプラインのステップ
- プロモーションおよびプロモーションのプルリクエスト/マージリクエストに関する意見や提案を募集します。
- ソース環境からターゲット環境にインベントリー・エントリーをプロモートします。
- プロモーションのプルリクエストまたはマージリクエストを作成してください。 プル/マージ要求を編集して、実行する変更を指定します。 オプション・フィールドおよび必須フィールドに注意してください。
- オプション。 エビデンス状況を設定し、集約されたエビデンス要約をプロモーションのプル/マージ要求に追加します。
- プル/マージ要求をマージします。
- この機能が有効になっている場合は、Slackに通知を送信します。
ステージとタスク
次の表は、プロモーション・パイプラインで実行されるタスクの一覧です。 さらに、この表には、これらの各段階の概要も示されています:
-
タスクまたはステージ :これは、
.pipeline-config.yamlの設定ファイル内で定義されているステージの名前を指します。 -
概要 :ここでは、このステージの実行中に実行されるアクションについて簡潔に説明します。
-
カスタマイズ可能 :これは、ユーザーが
.pipeline-config.yamlファイルにカスタムスクリプトを挿入することで、ステージのデフォルトの動作を変更または置き換えることができるかどうかを示します。 -
デフォルトのリファレンス実装 :これは、 DevSecOps のパイプラインに、そのステージ用の事前定義済みまたはデフォルトの実装が含まれているかどうかを示します。 特に、
unit-testsやsetupといった特定のステージについては、 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-testsやsetupといった特定のステージについては、 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 販売促進検証トリガーを有効にするには、以下のステップを使用できます。
- 追加先となる CD パイプラインの 「トリガー」 ページに移動します。
- 新規トリガーを追加するには、 「追加」> Git 「リポジトリー」 を選択します。
- トリガーに必要な以下の情報を入力します。
- トリガー名を指定してください。 例: Git Promotion Validation Trigger。
EventListenerとしてpromotion-validation-listener or promotion-validation-listener-gitlabを指定します。- 「 リポジトリー 」フィールドで、パイプラインに対応するインベントリー・リポジトリーを選択します。
- 「ブランチ」 のターゲット環境の名前を選択します。
- 「プル要求のオープン時または更新時 (When a pull request is opened or updated)」 フィールドのボックスにチェック・マークを付けます。
- 追加 をクリックします。
- トリガーを 「オン」 に設定します。
入力
| 変数 | 説明 | デフォルト値 | 必須またはオプション |
|---|---|---|---|
| source-environment | プロモーションのソース・インベントリー・ブランチ。 | master |
必須 |
| target-environment | プロモーションのターゲット・インベントリー・ブランチ。 | prod |
必須 |
| 優先 | 変更の優先度。 | critical、high、moderate、low、または planning |
オプション |
| assignee | 変更要求 IBM Cloud 組織で、この変更要求を割り当てる機能 ID または個人の E メール。 | '' |
オプション |
| 説明 | 変更要求の説明に付加される変更の説明。 | '' |
オプション |
| 目的 | 変更が必要な理由。 | '' |
オプション |
| impact | この変更の実施がどのような影響を与えるかについて、さらに補足します。 | '' |
オプション |
| インベントリ無視ファイル | .inventoryignore ファイルのカスタム ファイル名。このファイルには、部分プロモーションの実行ごとに無視するファイル/フォルダーのリストが含まれています。 | .inventoryignore |
オプション |
| 在庫を含める | 選択的にプロモーションする在庫エントリ(部分プロモーション)。 | '' |
オプション |
| 在庫除外 | 部分プロモーションで除外する在庫エントリ。 | '' |
オプション |
| backout-plan | 失敗した場合の変更のロールバック方法についての計画。 | '' |
オプション |
| slack-notifications | Slack 統合をオンまたはオフにするスイッチ。 | 0 | オプション |
| 顧客への影響 | 顧客に対する変更の影響。 | critical、high、moderate、low、または no_impact |
オプション |
出力と結果
- Slack 通知
- プロモーションのプル/マージ要求
オプション・パラメーターが指定されていない場合は、プル/マージ要求を編集および変更する必要があります。
| 変数 | 説明 | 必須またはオプション |
|---|---|---|
| 優先順位 | 以下のいずれかの値: Critical、 High、 Moderate、 Low、 Planning |
必須 |
| 変更要求の割り当て対象者 | 割り当て対象者の E メール ID。 | 必須 |
| 追加説明 | アプリケーションの変更点に関する説明。 | オプション |
| 目的 | アプリケーションに加えられた変更の目的。 | オプション |
| 影響の説明 | アプリケーションの動作や環境の変更による影響。 | オプション |
| 顧客の影響 | 以下のいずれかの値: Critical、 High、 Moderate、 Low、 No_Impact |
必須 |
| デプロイメントの影響 | 以下のいずれかの値: Small、 Large |
必須 |
| バックアウト計画 | デプロイメントが失敗した場合にバックアウトするステップ。 | オプション |
(オプションの) プロモーション PR 検証が実行されると、証拠状況がプル/マージ要求に設定されます。
証拠 (インベントリー内の複数のアプリから得られる可能性がある) の集約された証拠要約が、PR 内のコメントとして表形式で表示されます。
次のステップ
Promotion Pipeline が正常に終了したら、 CD パイプラインに進む ことができます。