昇進時の職務分掌

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

  • → プロモーション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-tests や setup といった特定のステージについては、 DevSecOps のパイプラインでは、そのまま利用できる実装は提供されていません。 その代わりに、ユーザーは、自身のアプリケーションの要件に合わせてカスタマイズしたスクリプトやコードを用意する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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

    my-application-dashboard
    my-application-dashboard_deployment

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

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

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

Deprecated プルリクエストに対してプロモーション検証パイプラインを自動的に開始するために使用されていた「 opt-in-promotion-validation 」オプションは、 Git Promotion Validation trigger への移行に伴い、 deprecated に変更されました。 環境設定にこのプロパティーがある場合は、パイプライン・ログと 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. トリガーを 「オン」 に設定します。

入力

出力と結果

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

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

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

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

プロモーション用プルリクエストの自動マージ機能

自動マージ機能は、「プロモーション検証パイプライン」によるすべてのステータスチェックが成功した場合、プロモーションのプルリクエストを自動的にマージします。 このオプション機能により、検証完了後の手動によるマージ作業が不要になるため、プロモーションのワークフローが効率化されます。

header['x-gitlab-event'] == 'Merge Request Hook' && body.object_attributes.target_branch.matchesGlob('staging')
 && (body.object_attributes.action == 'open' || body.object_attributes.action == 'update' || body.object_attributes.action == 'reopen')
&& (body.object_attributes.source_project_id == body.object_attributes.target_project_id) && !(body.object_attributes.action == 'update' && !body.changes.merge_when_pipeline_succeeds.previous && body.changes.merge_when_pipeline_succeeds.current)

次のステップ

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