ピアの管理-レビュー CI/CD ツールチェーンのチェックイン

この資料では、継続的統合 (CI) 内でのピア・レビュー検査の有効化と無効化、および Continuous Delivery (CD) ツールチェーン内でのオプションの有効化と無効化について説明します。

重要なポイント

ピア・レビューは、在庫が更新される保護 (ベース) ブランチでのみ実施する必要があります。 フィーチャー・ブランチで CI パイプラインを実行している場合は、その特定のトリガーの環境変数 peer-review-compliance を 0 に設定して、フィーチャー・ブランチでピア・レビュー・チェックが行われないようにします。

ピア・レビュー・コンプライアンスへの準拠は、継続的統合 (CI) パイプラインの実行が正常に完了し、その後の在庫へのエントリーが完了することを条件とします。 その結果、CI パイプラインの初回実行時に、ピア・レビュー準拠性検査がスキップされます。

ピア・レビュー標準に確実に準拠するために、 ci-finish ステージのインベントリー更新が master ブランチで行われることを前提としています。 ただし、在庫の更新がマスター以外の別のブランチで実行される場合は、環境変数 inventory-repo-branch を設定して、在庫の更新が行われているブランチを示すことができます。

継続的デプロイメント（CD）パイプラインでは、インベントリリポジトリで行われたすべてのインベントリ更新は、デプロイされるターゲットブランチに昇格し、コミットの取りこぼしがないようにすることが期待されています。 デフォルトでは、デプロイ時にインベントリリポジトリはターゲットブランチにチェックアウトされます。 しかし、インベントリプロモーションのターゲットブランチがベースブランチとターゲットブランチの間のコミットを見逃している場合、inventory-repo-branch 環境変数を設定して、すべてのインベントリコミットがあるベースブランチを指定することができます。

デフォルトでは、継続的統合 (CI) パイプラインは、インベントリー・エントリーとしてアプリケーション名を使用して、実行の終了時にインベントリー・リポジトリーへのコミットを自動的に実行します。 ただし、リリース・ステージでインベントリー項目を変更する場合は、 inventory-entry-name という名前の環境プロパティーをツールチェーンに組み込むことをお勧めします。 このプロパティーには、ピア・レビュー・プロセスで作業するために変更されたインベントリー名が含まれている必要があります。

保護されたブランチに直接コミットをプッシュするオートメーションを使用していて、ピアレビューのコンプライアンスチェックに関する問題を避けたい場合は、コミットメッセージに ##AUTOMATED_COMMIT## が含まれていることを確認してください。

リファレンス実装は、査読されていないコードのインスタンスを発見し、証拠 を収集し、これらの項目を追跡するためにインシデント問題を作成します。

master (protected) ブランチにあるコードをマージする前に、変更したコードをアップロードしていない人がそのコードをレビューする必要があります。

コード・リポジトリ（レポ）には、管理者権限を持つメンバーと、書き込み権限を持つメンバーの少なくとも2人のメンバーが必要です。 レビューせずにコードをリポジトリーにマージすると、このアクションはコード・リポジトリーの監査証跡に表示されます。 監査証跡を定期的にスキャンし、これらの例外状態を識別して分析してください。

パイプラインは、ビルドとデプロイ時にピアレビューのコンプライアンスデータを収集し、コードのプル/マージ要求のマージから変更要求までの監査証跡を作成する。

この図で、 PR1、 PR2 は、マージ前に承認されたプル/マージ要求です。 同様に、 PR4、 PR5、および PR7の場合も同様です。 ただし、赤で強調表示されている PR3 および PR6は、承認なしでマージされます。これはピア・レビューのコンプライアンス違反です。 これは証拠として収集されます。

デフォルトでは、CI ツールチェーン内のサンプル・アプリケーションは、レビューアーの最小数を 1 に設定しようとします。 レビュー担当者の数を変更する場合は、必要に応じて peer_review_approvers 環境プロパティーを設定します。 プル/マージ要求に必要なレビューアーの最小数の設定について詳しくは、以下の GitHub リソースおよび GitLab リソースを参照してください。

• GitHub:プルリクエストに複数のレビュアーを要求する
• GitLab: マージリクエストの承認ルール

継続的インテグレーションのビルド実行で収集されたデータ

このデータコレクションには、前回のビルド以降にアプリのリポジトリにマージされたプル/マージリクエストのすべてのコミットのリストが含まれています。

プル要求のデータはアプリのリポジトリーから直接収集されます。 前回のビルドのトリガーとなったレポのコミットから現在利用可能なコミットまでの間のコミットに関連するプル/マージリクエストのデータが収集されます。

プル/マージリクエストが含まれていないコミットは、パイプラインの次のリリースでコンプライアンスインシデントの問題を引き起こします。 masterブランチに直接コミットすることはできない。

コンプライアンス・インシデントには、通常、以下の情報が保持されます。

• 関連付けられたコミット ID のプル/マージ要求 URL のリスト。
• アプリケーション・リポジトリー。
• コミット ID。
• 必要な承認の数。

収集されたデータは、証拠品 として保存され、証拠品ロッカーにアップロードされ、証拠品自体で参照される。 最終的なエビデンスの結果は、承認されたプル／マージ・リクエストによって決定される。 未承認だがマージされたプル/マージリクエストは、このタイプの証拠に失敗する。

継続的なデプロイの実行で収集されるデータ

このデータコレクションには、前回のデプロイ以降にアプリのリポジトリにマージされたすべてのプル/マージリクエストのリストが含まれています。

プルリクエストデータは、エビデンスロッカーとインシデント課題レポから収集される。

• インベントリーには、すべてのビルドから、前回のデプロイメントの後の関連成果物に関するデータが収集されます。
• エビデンス・ロッカーには、保管されたピア・レビュー・データがビルドから収集されます。
• インシデント・イシュー・レポは、未解決のプル／マージ・リクエスト・インシデントに関する情報を収集する。

このデータ収集の間は、アプリのリポジトリーにはアクセスできません。 継続的デプロイメント・パイプラインは隔離された環境にあることが前提なので、その境界を越えることはできない。

変更要求の内容

自動生成される変更要求には、以下のデータが含まれます。

• 改善されていないプル/マージ要求インシデントのリスト。 このデータには、資産の詳細とインシデント URL が含まれます。

未修正のプル／マージ要求インシデントは、変更要求の展開準備に影響を与える。 プル/マージ要求のインシデントが検出された場合、それらは脆弱性と見なされ、 変更要求 を手動で確認して承認する必要があります。

プル要求インシデントの修復

プル要求インシデントは、リリースされる成果物に未検査のコードが含まれていることを示しているため、脆弱性と見なされます。 これらのインシデントを修復するには、以下の手順を実行します。

1. マージされた変更をさかのぼってレビューします。
2. コードの既存の問題を修正する方法についての Issue を作成します。
3. exempt ラベルを追加するか、プル/マージ要求インシデントの問題を閉じます。

プル/マージリクエストの作成者と、プル/マージリクエスト・インシデント・イシューをクローズする人を同一人物にすることはできません。

トラブルシューティング

case 1:

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

既知の問題

• ピア・レビュー・コンプライアンスは、継続的統合 (CI) パイプラインの各反復の後のリリース・ステップでの在庫エントリーの組み込みに依存しています。 失敗した CI パイプライン実行のインベントリー項目の組み込みをスキップすると、 Continuous Delivery (CD) パイプラインでその特定の CI パイプライン実行のピア・レビュー証拠が無視される可能性があります。