【要約】Vercel × Neon Preview Branching でPRごとのプレビュー環境を作る [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がVercelとNeonの統合機能を利用した際、Preview環境が本番DBを参照し続ける問題に直面する。この構成では、以下の技術的課題が発生する。
- ・本番データへの誤書き込みリスク：Preview環境が本番DBの書き込み権限を持つため、管理画面等の操作で本番データを破壊する恐れがある。
- ・スキーマ変更時のビルド失敗：Drizzle等のORMが全列をINSERTしようとするため、列追加を含むPRでは本番DBの古いスキーマと不整合を起こし、必ず失敗する。
// Approach
著者は、VercelのBuild Commandにマイグレーション処理を組み込み、環境ごとにDBブランチを分離する構成を提案する。具体的な解決策は以下の通りである。
- ・Preview Branchingの有効化：Vercelの設定でPreview環境用のDBブランチ生成を有効にする。
- ・Build Commandの拡張：
pnpm -w run db:migrate && turbo run buildのように、ビルド前にマイグレーションを実行する。 - ・直結エンドポイントの利用：マイグレーション実行時は、PgBouncerを介さない
DATABASE_URL_UNPOOLEDを使用する。 - ・自動クリーンアップ：GitHub Actionsを用い、PRクローズ時にNeonのブランチを自動削除してリソースを節約する。
// Result
この構成により、PRごとに「本番データ＋新スキーマ」を備えた安全な検証環境が自動的に提供される。導入によって以下の成果が得られる。
- ・スキーマ変更の安全な検証：本番環境に影響を与えず、新しいスキーマでの動作確認が自動で行える。
- ・本番DBの保護：Preview環境が独立したブランチを参照するため、本番データへの誤操作を構造的に防げる。
- ・デプロイの信頼性向上：マイグレーションの適用漏れがビルド失敗として検知されるため、デプロイ失敗のリスクが低減する。
Senior Engineer Insight
> 本構成は、インフラの自動化とデータの整合性を高度に両立させている。特にBuild Commandでのマイグレーション実行は、コードとスキーマの同期を強制する優れた設計だ。ただし、破壊的変更（列の削除等）においては、旧コードが新スキーマで動作する時間を考慮した「二段階デプロイ」が必須となる。この運用ルールをチームに徹底できるかが、実戦投入時の鍵となる。また、モノレポ環境ではマイグレーションの二重実行を防ぐ依存関係の設計が重要である。