こんにちは！！
株式会社UPSIDERの支払い.comでフロントエンドエンジニアをしていますOkahashiです！
今回は、支払い.comチームで活用しているフロントエンドのプレビューデプロイの仕組み について紹介します。
Backendのプレビューについても記事がありますので、ぜひチェックしてみてください！ tech.up-sider.com
そもそも、なぜPreviewが必要なのか
支払い.comチームでは、日々以下のようなフローで開発&リリースを行っています。
- mainブランチからfeatureブランチを作成し、mainブランチにマージする
- すぐにリリースできないものはscopeブランチを作成し、以下のフローで開発を行う
- scopeブランチからfeatureブランチを作成する
- featureブランチで開発を行い、scopeブランチへマージする
- scopeブランチでプレビュー環境を作成し、テストを行う
- scopeブランチをmainブランチへマージする
- mainブランチからリリースタグを作成し、リリースする 🔥
図にすると以下となります
（基本的な開発の流れ）
（複数のPRに跨った機能開発の流れ）
上記の開発フローに加えて、小さく早いリリースを実現するために 「mainブランチはいつでもリリースできる状態にしておく」 というルールも設けています。
そのため、
- mainへマージする前に基本的にテストが必要
- Bizメンバーへ「この内容でリリースしてもいい？」といった最終レビューはmainへマージする前に終わらせる必要がある
状態になっており、支払い.comチームでの開発にはプレビュー環境が欠かせません🤩
Previewのデプロイ方法
支払い.comのフロントエンドでは、Firebase Hostingのプレビューチャネルを利用してプレビュー環境を構築しています。
プレビューは、以下の2通りのデプロイ方法を用意しています。
① PRにラベルをつける
もっともよく使う方法です。
PRに 「preview」 ラベルを付けると自動でデプロイが始まり、完了するとBotがPRに以下のようなコメントを付けてくれます 🤖
「customer」 と表記されているのがメインのアプリケーションとなります。
同時にStorybookもデプロイされるので、コンポーネントの追加のみの場合でもStorybookを用いて確認ができます。
② 手動で実行する
workflow_dispatch により、ブランチを指定して任意のタイミングでPreviewをデプロイできるようにしています。
APIのエンドポイントもWorkflowのinputとして指定できるようにしているので、開発中のBackendと繋げたPreview環境も作れるようになっています 👍
PRを作成する前の段階でも利用できることがメリットですが、ほとんどの場合はPRにラベルを付ければ十分なためこの方法は使う頻度は少なめです🙃
工夫している点
① Backendのプレビュー環境にも対応しています
プレビューデプロイの際に、関連するPRのコメントにBackendのプレビューURLがある場合は、フロント側からそのAPIを使って動作するようになります 💖
これは特に大きめの機能を scope/xxx ブランチで進めるときに便利で、Backend・Frontendどちらも開発中でも、Previewを通してサクッとまとめて動作確認が可能です。
ブランチにBackendの差分が含まれる場合、バックエンドのプレビューがデプロイされ、PRに以下のようなコメントが追加されます。
(Backendのプレビューについてはレビュー効率アップ！Pull RequestごとにKotlin/KtorをCloud Runにプレビューデプロイするもぜひチェックしてみてください！)
このコメントを peter-evans/find-comment を利用して探し、フロントエンドのプレビューデプロイ時にAPIのエンドポイントとして与えます。
# Backendのpreview URLを探す
- name: Find Comment
if: github.event.pull_request.number
uses: peter-evans/find-comment@v3
id: find-comment
with:
issue-number: ${{ github.event.pull_request.number || steps.find-pr.outputs.number }}
body-includes: "Preview (backend)"
- name: Find API Preview
if: steps.find-comment.outputs.comment-body != null
id: find-api-preview
run: |
API_URL=$(echo "${{ steps.find-comment.outputs.comment-body }}" | grep -o 'https://preview-.*\.run\.app')
echo "API_URL=$API_URL" >> $GITHUB_OUTPUT
これにより、非エンジニアのメンバーに
「開発者ツールを開いてここの値を書き換えてね…!」
的なお願いをすることなく、気軽に開発中の機能を触ってもらえるようになっています！
② 使い終わったらすぐに閉じています
「preview」のラベルがついたPRがマージ/Closeされた際に、別のWorkflowによってプレビューチャネルを閉じています。
これにより不要なリソースが残りづつけることがなく、きれいに保てています👍 また開発チーム以外のメンバーにレビューしてもらう場合にも、過去に作成していた無関係のプレビューを見てしまうことを防げます 👍
(ささやかな気遣いとして、プレビューチャネルを閉じると同時にPRにつけられたコメントを編集しています🧘)
実際の活用例
🧪コードレビュー時の動作確認
レビュー担当者は、手元で動かさなくてもプレビュー環境で動作確認が可能なため、特にUIのちょっとした調整や動きの確認などで活用しています。
またマージ前の複数端末でのテスト時にも活用しています👍
🤝開発チーム以外の関係者によるレビュー
開発中の機能も、プレビューを共有することでサクッと実際に動作する状態で確認してもらえます。
デザイン段階では見落としてしまっていたものや、実際に画面上で見ると気になってしまった点などもクイックに確認&FBをもらって修正することができます。
プレビューによってFBのサイクルが早まり、リリース速度の向上につながっていると感じています 💪
おわりに
支払い.comチームでの開発では、プレビュー環境はなくてはならないツールになっています。 これからも、日々改善してくださっているフロントチームに感謝を込めてPRにPreviewラベルをつけていこうと思います🫶
We Are Hiring !!
支払い.comをはじめUPSIDERでは現在積極採用をしています。 ぜひお気軽にご応募ください。 https://herp.careers/v1/upsider herp.careers
カジュアル面談はこちら！ https://herp.careers/v1/upsider/NZVy179O5E08 herp.careers
Culture Deckはこちら📣 https://speakerdeck.com/upsider_official/upsider-culture speakerdeck.com
