【ITニュース解説】Automated frontend previews: Payfit’s path to faster PR reviews

ソフトウェア開発チームでは、新しい機能の実装後、そのコードが適切に動作するかを確認する「プルリクエスト（PR）レビュー」という重要なプロセスがある。これは、開発者が自分の変更したコードをチームの共通コードに統合してほしいとリクエストするもので、他のチームメンバーがコードを読み、問題がないかを確認し、承認することで初めて統合される。しかし、コードを読んだだけでは実際に画面上でどのように機能が動くか、見た目に問題はないかといった「フロントエンド」の変更点を確認するのは難しいという課題があった。

以前の状況では、チームがプルリクエストを出した後、レビュー担当者はコードの内容を読んで承認するか、開発者にスクリーンショットを要求するしかなかった。スクリーンショットだけでは不十分な場合、レビュー担当者は開発ブランチのコードを自分のパソコンにダウンロードし、手動で起動して動作を確認する必要があった。この一連の作業は非常に手間がかかり、レビューが終わるまでに数日を要することも珍しくなかったため、新しい機能を素早く市場に投入する「開発速度（ベロシティ）」が低下する原因となっていた。

この問題を解決するため、チームは「Front-on-Demand」という仕組みを試みた。これは、各開発チームが、本番環境に近いテスト用の「ステージング環境」を一つずつ持ち、レビューが必要なときに手動でその環境にアプリをデプロイする、というものだ。しかし、この方法にはすぐに限界が見えた。まず、一つのチームが使えるステージング環境は一つしかなかったため、複数の開発者が同時にレビューを求めても、一度に一つのアプリしかデプロイできず、順番待ちが発生する「順次ボトルネック」が生じた。また、開発者はアプリを手動でデプロイする方法を常に覚えておく必要があり、手間がかかる「手動オーバーヘッド」の問題もあった。さらに、使われていないステージング環境はただリソースを消費するだけであり、「リソースの無駄」も無視できなかった。

そこでチームは、より良い方法を模索し、「PR Previews on Autopilot」という画期的なシステムへと移行した。これは、プルリクエストが作成されるたびに、そのプルリクエスト専用のプレビュー環境が自動で作成され、そのプレビューURLが自動で提供される仕組みだ。そして、プルリクエストが閉じられたり統合されたりすれば、そのプレビュー環境も自動で削除される。この「プレビュー環境」を、開発プロセス全体の核となる「CI/CDパイプライン」（継続的インテグレーション/継続的デリバリー。コードの変更を自動的にテスト・デプロイする一連の流れ）の重要な要素と位置付けたのだ。

この自動化を実現するために、まず「Nxエクゼキュータ」と呼ばれるカスタムツールを作成した。Nxとは、大規模なプロジェクト、特に複数のアプリケーションやライブラリが一つのリポジトリにまとめられた「モノレポ」と呼ばれる開発環境を効率的に管理するためのツールである。通常、アプリごとにデプロイスクリプトを個別に書く必要があるが、このNxエクゼキュータを使うことで、モノレポ内のすべてのフロントエンドアプリで共通して使える、単一で設定可能なデプロイツールが実現した。このエクゼキュータは、以下のステップでプレビューデプロイを行う。まず、現在の開発ブランチが何か、どのプルリクエストに関連しているかを特定する。次に、アプリがビルドされた成果物（ウェブサイトとして表示するためのファイル群）をAWSのストレージサービス「S3」にアップロードする。最後に、デプロイが完了したこととプレビューURLを、GitHubなどのコード管理ツール上でプルリクエストのコメントとして自動投稿し、関係者全員に通知する。

Nxは、このシステムの基盤として非常に重要な役割を果たす。Nxは「モノレポアーキテクチャ」の特性を理解しており、複数のアプリやライブラリ間の依存関係を正確に把握する。これにより、コード変更がどのアプリケーションに影響を与えるかを自動的に検出し、必要な部分だけをビルド・デプロイする「Affected Project Detection」機能を提供する。開発者はどのアプリを手動で設定すべきか悩む必要がなく、Nxが自動的に判断してくれるのだ。また、Nxの「エクゼキュータシステム」のおかげで、新しいアプリをプレビューシステムに組み込むのも非常に簡単になった。プロジェクトの設定ファイルに previewDeploy: true というメタデータフラグを追加するだけで、自動的にプレビューデプロイの対象となる。チームは「yarn nx affected -t publish-preview」という単一のコマンドをCI/CD環境で実行するだけで、影響を受けるすべてのアプリのプレビューが自動的に作成されるようにした。

インフラ面では、AWSの複数のサービスを組み合わせて「インフラマジック」を実現した。主要なのは、S3、CloudFront、そしてLambda@Edgeの三つである。まず、Nxエクゼキュータによってビルドされた各プルリクエストのアプリは、AWSのオブジェクトストレージサービスであるS3に特定のパスでアップロードされる。このパスは、例えば「PR番号-アプリ名」の形式（例: s3://バケット名/123-foo）で、各プレビューが一意に識別できるように工夫されている。また、変更がすぐに反映されるよう、キャッシュを無効にする設定でアップロードされる。

次に、このS3バケットをコンテンツ配信ネットワーク（CDN）である「CloudFront」のオリジンとして設定する。CloudFrontは世界中のユーザーにコンテンツを高速に配信するためのサービスで、ここではS3に保存されたウェブサイトのファイルを配信する役割を担う。そして、このCloudFrontと連携するのが「Lambda@Edge」という機能だ。Lambda@Edgeは、CloudFrontの各エッジロケーション（ユーザーに近い配信拠点）でコードを実行できるサーバーレスなコンピューティングサービスである。チームは二つのLambda@Edge関数を使用した。一つは、CloudFrontがデフォルトで公開されるエンドポイントをセキュリティで保護するため。もう一つは、ユーザーがアクセスするURLを、S3に保存されている実際のパスに書き換えるためだ。具体的には、「https://{PR番号}-{アプリ名}.preview.my-domain.com」のような、開発者にとって分かりやすい「クリーンなURL」でプレビューにアクセスできるようにする。例えば、PR番号123の「foo」というアプリであれば、https://123-foo.preview.my-domain.com となる。Lambda@EdgeはこのURLのサブドメイン部分（123-foo）を読み取り、S3上の /123-foo というパスにリクエストを内部的にルーティングする。この仕組みにより、たった数個のLambda関数と一つのCloudFront、一つのS3バケット、そしてNxのコマンドだけで、ほぼ無限の数のアプリとプルリクエストに対応できる、スケーラブルなプレビューシステムが完成した。

この新しいシステムを導入したことで、開発プロセスには劇的な変化が訪れた。最も顕著なのは、レビュー時間の短縮である。正確な数値は測定できなかったものの、その短縮は体感できるほど大きかった。レビュー担当者は、数分以内には実際に動作する変更点を見て、テストできるようになり、自信を持って承認できるようになった。これにより、開発者の満足度も飛躍的に向上した。「この変更をデプロイして見せてくれますか？」「いまプレビュー環境は空いていますか？」といった、非効率なコミュニケーションが Slackなどのチャットツールで交わされることもなくなった。

自動化されたPRプレビューシステムの構築は、フロントエンドアプリのコードレビュー方法を根本から変革した。かつては手動でエラーも多く発生しやすいプロセスだったものが、スムーズで自動化された開発体験へと生まれ変わったのだ。この成功の鍵は、プレビューと「開発者体験」を、開発プロセスの後回しにするのではなく、その中心に据えたことにある。Nxのエクゼキュータやそのキャッシュ機能、AWSのLambdaとCloudFrontといったインフラ、そしてGitHub Actionsなどの自動化ツールを適切に組み合わせることで、チームの成長に合わせてスケールし、最新のアプリを2分以内にデプロイできる高速なシステムが構築され、その上でメンテナンス作業もほとんど不要となったのである。