【要約】PR ごとにプレビュー環境が立ち上がる CI/CD 構成を作った話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が「tacos DB」の開発において、コードの変更内容を視覚的に確認するための環境構築に課題を感じていた。具体的には、以下のペインポイントが存在した。
- ・コードレビューのみでは、店舗一覧やCMSの入力画面といったUI/UXの変更を正確に把握できない。
- ・外出先などのモバイル端末から、実際の挙動を迅速にレビューする手段が不足していた。
- ・開発の初期段階において、デプロイフローが未整備であり、開発リズムを阻害する懸念があった。
// Approach
開発者が、PRごとに視覚的な確認を行えるよう、CloudflareとGitHub Actionsを用いた自動化を実現した。以下の手法を採用している。
- ・GitHub Actionsでファイルパスの差分を検知し、PagesやWorkersのプレビューURLをPRコメントに自動投稿する。
- ・DB（D1）はコストと複雑性を考慮し、プレビュー時はdev環境を共有する設計とした。
- ・D1 migrationの適用条件を、環境（dev/prod）やデプロイの種類に応じて厳格に制御するロジックを実装した。
- ・Terraformでインフラの土台を管理し、GitHub Actionsでアプリのデプロイを担う役割分担を徹底した。
// Result
開発者が、開発開始から約2週間で、devおよびprod環境へのデプロイパイプラインを構築した。これにより、以下の成果を得ている。
- ・PRごとのプレビュー環境により、開発サイクルとレビューのスピードが格段に向上した。
- ・DBマイグレーションの運用方針を早期に確立したことで、安全なスキーマ変更が可能となった。
- ・インフラ管理とアプリデプロイの責務を分離し、保守性の高い構成を実現した。
Senior Engineer Insight
> サーバーレススタックを最大限に活用した、極めて合理的かつ実践的な構成である。特に、D1のマイグレーション制御において、環境ごとに適用条件を分岐させている点は、運用の安全性と開発速度のバランスをよく理解している。ただし、プレビュー環境がdev環境のDBを共有する設計は、データ整合性の観点から注意が必要だ。大規模開発へスケールさせる際は、DBの隔離（Ephemeral DB）を検討すべきだが、本構成はコスト効率を重視した優れた初期設計と言える。