記事一覧へ

ステージング環境を活用して、PRごとにフロントエンドをプレビューする

バックエンドとデータベースはステージング環境のものを使い、フロントエンドだけをPRごとに切り替える「FrontendPreview環境」を、CloudFront Functionsで実現した仕組みを紹介します。

私が所属している株式会社フライルでは、AIを活用した開発を積極的に行っている。 例えば、Slack経由でDevinとやりとりしながらPRを作成できるため、PdM、QA、デザイナーといった開発者以外のメンバーもPRを作る機会がある。 変更内容はさまざまだが、UIの軽微なバグ修正や文言の調整など、フロントエンドだけで完結するPRも多かった。

一方で、PRを作れても、その変更を手元で動かして確認するには準備が必要になる。 ローカル環境を立ち上げ、動作確認に必要なデータを用意するのは、特に普段開発環境を触らないメンバーにとって負担が大きい。

そこで、既存のステージング環境を使い、PRごとのフロントエンドの変更を確認できる「FrontendPreview環境」を作成した。

FrontendPreview環境でできること

社内には、最新の develop ブランチを動作確認できるステージング環境がある。 この環境にアクセスできるのは社内メンバーのみで、PRの作成やプレビュー環境へのデプロイも社内メンバーに限られる。 そこには各メンバーがテスト用に作成したテナントや、動作確認用のテストデータがすでに入っている。 FrontendPreview環境で利用するのも、このテストデータだ。

FrontendPreview環境では、バックエンドとデータベースはそのまま使い、ブラウザに配信するフロントエンドだけをPRごとのものに切り替える。 既存のテストデータを使って変更を確認できるので、PRごとにデータを一から用意する必要がない。

また、確認したいPRのプレビュー用URLをチームメンバーに共有すれば、同じPRのフロントエンドを使って動作確認やフィードバックができる。

FrontendPreview環境の仕組み

ステージング環境はAWS上に構築している。 フロントエンドのHTML・JavaScript・CSSなどのアセットはS3に保存し、CloudFront経由で配信している。

この配信経路にあるCloudFront FunctionsでCookieを読み取り、リクエストのURIを書き換えるのが今回の仕組みだ。

CloudFront FunctionsがCookieに応じて通常のFrontendとPRごとのFrontendを切り替え、BackendとDatabaseはステージング環境を共有する構成図

PRのビルドからプレビューまで

PR番号が 123 の場合、次の流れで動作する。

  1. PRに /deploy-frontend-preview とコメントする。
  2. AWS CodeBuildが起動し、そのPRのフロントエンドのアセットをビルドする。生成したアセットは、ステージング環境で使っているS3バケットの previews/pr-123/ 配下に配置する。
  3. 確認するメンバーが <通常のステージングURL>/__preview/set/pr-123 にアクセスすると、そのブラウザに fe_preview=pr-123 というCookieが設定される。
  4. 以降のフロントエンドへのリクエストで、CloudFront FunctionsがCookieを読み取る。fe_preview=pr-123 があれば、URIの先頭に /previews/pr-123 を付け、PR用のアセットが配信されるようにする。

例えば、/assets/app.js へのリクエストは、CookieがあればCloudFront側で /previews/pr-123/assets/app.js に書き換える。Cookieがなければ、通常のステージング環境のアセットを配信する。

ここで書き換えるのはCloudFrontが扱うリクエストのURIなので、ブラウザでアクセスするドメインは通常のステージング環境と同じままだ。バックエンドAPIの向き先も変えず、フロントエンドの配信対象だけを切り替えている。

この仕組みによって、ステージング環境を間借りしながら、フロントエンドの変更だけを簡単に確認できるようになった。

バックエンドの変更も含む場合

この環境で確認できるのは、ステージング環境のバックエンドで動作するフロントエンドの変更だ。 そのため、バックエンドの変更を含むPRをデプロイしようとすると、FrontendPreview環境ではプレビューできない旨の警告を出すようにしている。

バックエンドも含めて確認したい場合には、別途「PR環境」がある。その仕組みについては、以下の記事で紹介されている。

おわりに

今回の仕組みは、Claude Codeと壁打ちしながら形にした。 以前の自分なら、このアイデアをすぐに思いつけたかはわからない。CloudFront FunctionsまわりのTerraformコードもClaude Codeが書いてくれて、大変助かった。

「こういう仕組みが欲しいけれど、実装するのは少し大変そう」と感じていたものを、気軽に試せるようになったのはありがたい。 AIを使ってPRを作れるメンバーが増える中で、その変更を動かして確認するところまで手軽にできるようにしていきたい。

また、株式会社フライルではソフトウェアエンジニアを募集中なので、興味があればご連絡ください。