🌟

【Git×Vercel】本番・プレビュー環境の構築ガイド

に公開
Git
GitHub
Vercel
preview
tech

はじめに

本手順書では、Git連携とVercelを使って、ブランチと環境（本番/プレビュー環境）を運用する方法をまとめます。

対象者

  • Vercelを使ったNext.js等のホスティングを始めたい人
  • プレビュー環境と本番環境の役割分担や、設定の分離をしたい人
  • 個人開発者・小規模チーム

ゴール

リポジトリのブランチとデプロイ先の環境を次の規則で運用できるようにします。

  • main：本番ブランチで、マージ時に Production 環境へ反映される
  • preview：プレビューブランチで、プッシュ時に Preview 環境へ自動デプロイされる
  • develop：開発用ブランチで、必要に応じて Preview 環境にデプロイする
  • デプロイ環境：本番は example.com、プレビューは preview.example.com を使用する
  • 環境変数：Development、Preview、Production ごとに完全分離する

Vercel とは

https://vercel.com/
Next.jsを開発したチームが提供するフロントエンド向けのクラウドプラットフォームであり、Git連携による自動デプロイ、CDNによる高速配信、サーバーレス機能などを備えています。特に、GitHub等と連携し、ブランチやPR単位でプレビュー環境を自動生成できる点が大きな特徴です。個人開発からチーム開発まで幅広く利用され、インフラ構築を意識せずに本番・検証環境を整えられるのが強みです。

Vercelには、本番環境（Production）とプレビュー環境（Preview）が標準で用意されています。
本番環境は、 main ブランチにデプロイされ、安定稼働と信頼性を担保するための場所です。
プレビュー環境は、PRやブランチに応じて自動生成される「検証用の場」であり、安全に挙動を確認できるためぜひ活用したい機能です。

今回はこれらの環境（本番/プレビュー環境）とのGit連携による運用のお話になります。

1. Git連携とブランチ戦略

ブランチは役割に応じて固定命名し、mainにマージされたものだけが本番反映されます。
あらかじめローカルでブランチは以下のように切っておきます。

  • main … 本番運用専用。
  • preview … プレビュー確認用。
  • develop … 開発用。必要に応じて preview に統合する。フィーチャーブランチは feature/ で管理する

2. 環境変数の分離と命名規則

環境変数は必ず環境ごとに分離し、名称にも環境を埋め込んで事故を防ぐ

命名例

  • NEXT_PUBLIC_API_BASE_URL_DEV
  • NEXT_PUBLIC_API_BASE_URL_PREV
  • NEXT_PUBLIC_API_BASE_URL_PROD

※以下のように、サーバーサイド用のシークレットも同様に分離する

  • DATABASE_URL_DEV
  • DATABASE_URL_PREV
  • DATABASE_URL_PROD

3. Vercelの設定手順

プロジェクト作成

  1. GitHubのリポジトリを接続する
  2. Production Branch を main に指定する（production 以外のブランチへの push は自動で Preview デプロイになる。preview ブランチを個別指定する必要はない）
  3. ビルドコマンドと出力ディレクトリを確認する

ブランチとデプロイの対応

  • main へのマージで Production デプロイ
  • main 以外へのプッシュで Preview デプロイ（たとえば preview ブランチや develop ブランチも push するたびに自動で Preview 環境が作成される）

環境変数の設定

  • Development ローカル実行用の値を登録する
  • Preview preview 向けの値を登録する。
  • Production 本番向けの値を登録する

カスタムドメインの設定

  • example.com を Production に割り当てる
  • preview.example.com を Preview に割り当てる

4. データベースと周辺サービス

プレビューと本番でデータを混在させないため、サービスも環境ごとに分離する

分離の基本

  • DBはPreview用とProduction用を分ける
  • ストレージやキャッシュも環境ごとに分ける
  • 認証プロバイダーのクライアントIDとSecretも環境ごとに発行する

5. よくあるトラブル

  • preview と main で同じ環境変数を使ってしまう → データが混ざる危険
  • プレビュー用のOAuthリダイレクトURLを登録していない → 認可エラーになる
  • Cookieのドメインを共用してしまう → セッションが衝突する
  • 本番とプレビューで同じDBを使う → テストデータが本番に混入する
  • 手動でデプロイしてしまう → どの差分が反映されたのか追跡できない

おわりに

本番/プレビュー/開発環境の3本軸で役割を明確化し、環境変数やDB等を完全分離することで事故を防げます。Vercel は安定した開発体制を支えてくれる強力なサービスです。本記事が参考になれば幸いです。

株式会社ONE WEDGE

【Serverlessで世の中をもっと楽しく】
ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
https://onewedge.co.jp/

GitHubで編集を提案

Discussion