AI生成コードに対応、CI パイプラインの高速化が急務

継続的インテグレーションと継続的デプロイメントはしばしば単一パイプラインに混同されるが、異なる問題に答える。CI は「この変更は正しいか？」をリント、型チェック、ユニットテスト、エンドツーエンドテストで PR マージ前に実行することで答える。CD は「この変更は本番環境で安全か？」と問い、マージ後にデプロイメント、ロールアウト、ロールバックを処理する。本記事は第 1 部に焦点を当てている。フロントエンドプロジェクト向けの高速 CI パイプラインの構築だ。

従来のアプローチはすべてのプルリクエストでテストスイート全体とビルドを実行する。Dashboard、Settings ページ、Billing ページ、共有コンポーネントを備えた典型的なモノレポアプリでは、Button.tsx の 1 行を変更すると、すべてのファイルのリント、プロジェクト全体の型チェック、全 340 ユニットテストの実行、アプリのビルドが トリガーされ――25 分の待機が、あなたの後ろで待機しているすべての開発者にカスケードする。AI が現在ほぼすべてのコードを生成し、テスト生成を優先する現在、この指数関数的遅延は重大になりつつある。

筆者は、インポートグラフから PR に実際に影響を受けるファイルを計算することを提案している。Button.tsx が変更される場合、Button 自体のテストと Button をインポートするファイルのテストのみが実行されるべき。Billing は Button をインポートしないため、触れるべきではない。これには 3 つのステップが必要だ。第一に、git に変更ファイルを問い合わせる（git diff --name-only origin/main...HEAD）。第二に、インポートグラフを逆方向にたどって、変更ファイルを直接的または間接的にインポートするすべてのファイルを見つける。第三に、そのリストをリント、型チェック、テストランナーに、3 つのケース（すべて変更、何も変更されない、または特定リスト）を処理するラッパースクリプト付きで手渡す。

重要な実装詳細として、GitHub Actions パスフィルター（ワークフローを特定フォルダに制限）はスケールしない――すべての機能に新しいワークフローファイルが必要で、すべてのリネームは古い参照を探し回る必要がある。さらに悪いことに、ワークフローが開始されない場合、GitHub のブランチ保護の必須チェックは永遠に待機し、それらのパスに触れないプルリクエストでマージをブロックする。修正は、すべてのプルリクエストですべてのワークフローを実行し、ワークフロー内でジョブを条件付きでスキップすることだ。

このメソッドはラップトップでは機能するが、CI ランナーで失敗する。actions/checkout はデフォルトで fetch-depth: 1 を使用し、1 つのコミットと origin/main との比較先を残す。解決策は fetch-depth: 0 を設定して完全な履歴をダウンロードし、filter: blob:none を設定してチェックアウトしないコミットのファイル内容をスキップすることだ（必要に応じて git が要求時にそれらをフェッチする）。BASE_REF 環境変数もハードコードではなく origin/${{ github.base_ref }} に動的に設定されるべきで、各プルリクエストが相互にターゲットしている場合でも正しく機能する。

これらの変更により、ボタンコンポーネント変更は影響を受けた 4 ファイルのリントと型チェック、および 2 つのテストファイルのテストを数秒で実行する。README 変更はすべての 3 つのジョブを npm 依存関係インストール完了前に終了させる。すべての必須チェックはすべてのプルリクエストでステータスを報告するため、欠落チェックがマージをブロックすることがない。この記事は dependency-cruiser がインポートグラフウォークを自動化できることに注目し、TypeScript をパースし、tsconfig パスを読み、動的インポートをフォローし、手書きスクリプトを 1 つのフラグで置き換える：npx depcruise src --affected origin/main --output-type json。シリーズの第 2 部は CD――可逆的ロールアウト――に取り組む。

この記事が指摘する実際のボトルネックは以下の通りだ。AI がコードを生成し、特にテスト生成を優先する現在、すべてのプルリクエストですべてのチェックを実行する CI パイプラインが指数関数的な遅延を招いている。この問題は、大多数の CI ワークフローの構造によってさらに増幅される。ワークフローはパスフィルター（例えば、src/features/settings/* が変更された場合のみ Settings CI を実行）で トリガーされるが、このアプローチはスケール時に失敗する。理由は、すべての機能に対してワークフローファイルを手動で保守する必要があり、インポート関係を理解せず、トリガーされないワークフローの必須チェックが永遠に「待機」状態に陥るからだ。

筆者の解決策は問題を反転させる。コード検査前にどのパスがどのチェックをトリガーするかを宣言する代わりに、すべてのプルリクエストですべてのワークフローを実行し、各ジョブ内でスクリプトが git diff を分析して変更ファイルを見つけ、インポートグラフを逆方向にたどって、それらの変更に依存する他のファイルを計算する。影響を受けたファイルのみがリント、型チェック、テストされる。単一のボタンコンポーネントが変更された場合、スクリプトはボタンのインポーター 2 つとそれをカバーするテストを特定し、合計 4 ファイル――340 以上のテストスイート全体ではなく――テストする。README が変更された場合、3 つのジョブすべてが npm の依存関係インストール完了前に終了する。

Google はすでに同様の戦略を実装しており、同社の新規コードの大多数は AI 生成で、エンジニアが承認している。この記事は「検証を低コスト化しロールアウトを可逆的にする」というフレーミングを採用しており、これは CI/CD の 2 つの半分にマッピングされる。ここでの低コスト検証（重要なものだけをテスト）と、その後の可逆的ロールアウト（マージされた変更が本番環境で障害を起こした場合、迅速なロールバック）。

まだコメントがありません。最初のコメントを投稿しましょう！