CodePipelineを活用してCI/CDパイプラインの実行時間を抑えながら自動テストを強化しました

2025年当時、弊社では多くのプロダクトでAWS CodeBuildをCI/CDパイプラインそのものとして利用していました。
AWS CodeBuildはその名のとおりCI/CDパイプラインの中でもビルド処理を担うサービスですが、パイプラインがシンプルなビルド処理で間に合うのであれば、CodeBuildのみでパイプラインを構築することは実用上多いと思います。

今回CodePipelineを導入した、弊社の主要事業であるアップガレージのサービスサイト（https://www.upgarage.com/）のフロントエンドアプリケーションでも、パイプラインは当初単一のCodeBuildプロジェクトで構築していました。

2024年にEC機能をリニューアルした際に Playwright を商品検索ページに導入し、しばらくはCI上でも実行していました。ところが、その後テストを他ページにも拡充したところCIの実行時間が大幅に長くなってしまい、開発やリリース作業に支障を来すため一時的に停止せざるをえなくなりました。

商品検索ページはリニューアル後も継続的に機能改善を行っており、開発による既存機能への影響を考えると Playwright を利用しない状態は非常に危険でしたので、 Playwright の復旧をマネージャーチームに強く上申し、承認を頂きました。

最初は別の方が Playwright の実行プロセスの改善による時間短縮を試みましたが上手くいかなかったため、ワークフローを並列化して時間短縮する方針を変更し、CodePipelineの導入に至りました。

2025年当時は原則としてCI/CDパイプラインをAWSに構築する方針だったため、サービスの比較は行っていません。

ただし、オーケストレーション機能が近年充実してきているGitHub Actionsを現在一部のアプリケーションで試験的に導入しており、今ならGitHub Actionsも検討対象になったと思います。（GitHub Actionsを司令塔として、リントなど軽微なプロセスをGitHub Actionsで賄い、各種自動テストなど重めのプロセスやAWSと連携するCD部分をCodePipelineに任せる、といったハイブリッド方式が最近のトレンドかと思います。）

改善したかった課題はどれくらい解決されたか

元々は単一の CodeBuild プロジェクトでリント、ユニットテスト、E2Eテストをすべて直列で実行する構成になっており、60分以上かかっておりました。（毎回CIの実行に60分以上かかるのが運用に耐えないことは明らかなので正確な時間は計っておりません。）

CodePipeline に移行したことで、デプロイ用パイプラインでは15分、プルリクエスト用パイプラインでは20分に時間を短縮できました。

なお、今回のケースでは、推計で月間150ドル程度のコスト増加となりました。（他にもコスト変動の要因が多数あるため正確な計測はできていません。）

どのような成果が得られたか

CIへの Playwright 導入と実行時間の短縮を両立したことで、商品検索ページの不具合を開発中に迅速に検知できるようになりました。

CodeBuildからCodePipelineへのパイプライン移行で最も大変だったのは、CodeBuildプロジェクト単体のパイプラインで使用していた環境変数のほとんどが使用できなくなり、GitHubリポジトリからのデータの取得を設定しなおす必要があったことです。

元々、アクションの実行制御や、CIの結果をSlackに通知するために、GitHubのリポジトリ名、プルリクエストのID、リリースタグなどビルドトリガーの情報を環境変数から取得していました。変更前はビルドのトリガーがGitHubだったので、CodeBuild側で用意されている環境変数を参照すれば必要な情報をすべて取得できました。

今回ビルドトリガーがGitHubではなくCodePipelineになったことで、GitHubに関する情報はCodePipelineから渡さなければなりませんでした。しかし、AWSの公式ドキュメントにCodePipelineから渡せる環境変数に関する完全な情報が記載されておらず、実際に渡されている環境変数をすべて確認するにはCodePipelineコンソールを参照する必要がありました。（AWSは非常に便利なサービスですが、ドキュメントの品質がよくないことがあるのが玉に瑕ですね。。。）