Skip to main content

第14章：複数環境（staging/prod）を運用できる形にする🏗️

この章はひと言でいうと、**「うっかり本番を壊さない仕組み作り」**です😇💥 PRプレビューや自動デプロイが回り始めると、次に必要になるのが staging（検証） と prod（本番） の分離です🌿🚢

まず押さえる言葉📚✨（ここ超大事！）​

  • 環境（staging/prod）：ずっと存在する“運用場所”🏠（検証用・本番用）
  • Hosting の site（サイト）：同じFirebaseプロジェクト内に複数作れる“公開先”🌐（最大36） ただし 同じプロジェクトの他リソース（DB等）にアクセスできる＝危険もある⚠️ → **環境をミラーするなら「環境ごとに別プロジェクト推奨」**と公式が明言しています🧯 (Firebase)
  • Preview channel（プレビュー）：PRなどの一時公開URL（期限つき）🔎⏳ しかも プレビューでも本物のFirebaseリソースを触るので、使い方を間違えると本番汚染が起きます😱 (Firebase)
  • deploy target：firebase.json から “どのサイトに出すか” を名前で指定できる仕組み🏷️ .firebaserc に設定が保存されます🧩 (Firebase)

今日のおすすめ運用パターン🍱（結論）​

✅ パターンA：プロジェクトを分ける（staging/prod） ←いちばん安全🛡️​

Environment Patterns

  • myapp-stg（検証）と myapp-prod（本番）みたいに Firebaseプロジェクトを2つ作る✨
  • 公式も「環境ミラー目的なら、同一プロジェクトで複数サイトより別プロジェクト推奨」と言っています👍 (Firebase)
  • App Hostingでも「prod/stagingを別プロジェクトにデプロイ」ガイドが公式で用意されています📘 (Firebase)

◇ パターンB：同一プロジェクト内で複数Hosting site（マルチサイト）🧩​

  • “Webの見た目だけ” 変えたいとか、何か理由があるならアリ
  • でも DB/Storage/Functionsなどが同じプロジェクト＝本番データに触れやすいので慎重に⚠️ (Firebase)

この章のハンズオンは A（推奨）→B（応用） の順でいきます🚀

読む📖：staging/prod を分けると、何が嬉しい？😆​

  • 検証で失敗しても本番は無傷🕊️
  • PRプレビューが “staging側のリソース” を使うようにできる（本番汚染を防ぐ）🧯 (Firebase)
  • Secrets（鍵）や権限も 環境ごとに分離できる🔐（漏れても被害を局所化）

手を動かす🛠️（ハンズオンA：別Firebaseプロジェクト方式）🏗️🛡️​

0) ゴール設定🎯​

Git Flow to Environments

  • develop ブランチに push → stagingへ自動デプロイ🌿🤖
  • main ブランチに push → prodへ自動デプロイ🚢🤖
  • PR → staging側でプレビューURLを自動作成🔎✨（本番触らない）

1) Firebaseプロジェクトを2つ用意する🏗️🏗️​

  • コンソールで myapp-stg と myapp-prod を作成
  • それぞれ Hosting を有効化🌐

（ここはUI作業なのでサクッとでOK👌）

2) ローカル（Windows）でCLIに「別名」を登録する🏷️💻​

CLI Aliases

プロジェクトを切り替えミスすると終わるので、“毎回どっちに出してるか”が見える状態にします👀✨

PowerShellで👇

## 例：staging を alias に追加
firebase use --add

## 例：prod を alias に追加
firebase use --add

この結果、.firebaserc に 複数プロジェクトの紐付けが入ります（内容は環境で変わるけどイメージはこんな感じ）👇 (Firebase)

{
  "projects": {
    "staging": "myapp-stg",
    "prod": "myapp-prod"
  }
}

以後は、デプロイ時にこう書けます👇（ミス防止！）

## stagingへ
firebase deploy --project staging

## prodへ
firebase deploy --project prod

3) GitHub Actionsを「環境ごと」に分ける🤖🔁​

Firebase公式の GitHub 連携は「PRでpreview」「mergeでlive」まで用意してくれます📦✨ (Firebase) ただ、staging/prodを分けるなら、ワークフローも分けると気持ちいいです😌🌿

ここでは GitHub Action の FirebaseExtended/action-hosting-deploy を使います（公式手順でも出てくる定番）🧰 (GitHub) このActionは projectId（どのプロジェクトか）や target（どのサイトか）を指定できます👍 (GitHub)

✅ staging用（develop → stagingへ自動デプロイ）🌿🤖​

Staging Pipeline

.github/workflows/deploy-staging.yml 例👇

name: Deploy (staging)

on:
  push:
    branches: [develop]

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm ci
      - run: npm run build

      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_STAGING }}"
          projectId: myapp-stg
          channelId: live

※ Nodeは 2026-02 時点だと Node 24 がLTS入りしているので、CI側は 24 を選ぶのが無難です🟩 (nodejs.org)

✅ prod用（main → prodへ自動デプロイ）🚢🤖​

.github/workflows/deploy-prod.yml 例👇

name: Deploy (prod)

on:
  push:
    branches: [main]

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm ci
      - run: npm run build

      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_PROD }}"
          projectId: myapp-prod
          channelId: live

✅ PRプレビュー（PR → staging側でpreview URL）🔎✨​

ポイントはこれです👇 プレビューでも本物のFirebaseリソースを触るので、prod側でPRプレビューしないのが安全です🧯 (Firebase)

.github/workflows/preview.yml 例👇

name: Preview (staging)

on:
  pull_request:
    branches: [develop]

jobs:
  build_and_preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm ci
      - run: npm run build

      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_STAGING }}"
          projectId: myapp-stg

4) Secrets（鍵）を環境ごとに分ける🔐🧰​

Secrets Separation

  • GitHubのSecretsに

    • FIREBASE_SERVICE_ACCOUNT_STAGING
    • FIREBASE_SERVICE_ACCOUNT_PROD を別々に登録します🗝️

GitHub連携のセットアップは、公式手順で「サービスアカウント＋Secrets」を作る流れが説明されています📘 (Firebase)

手を動かす🛠️（ハンズオンB：同一プロジェクトでマルチサイト＋target）🧩​

「同じFirebaseプロジェクト内で、stg用サイトとprod用サイトを分けたい」場合の型です🏗️ ただし 同一プロジェクト内の他リソースを共有する点は忘れずに⚠️ (Firebase)

1) Hosting site を追加する🌐➕​

firebase hosting:sites:create myapp-stg
firebase hosting:sites:create myapp-prod

siteの作成コマンドは公式に載っています✅ (Firebase)

2) deploy target を割り当てる🏷️​

Deploy Targets

firebase target:apply hosting staging myapp-stg
firebase target:apply hosting prod myapp-prod

この仕組みとコマンドは公式の “Deploy targets” に明記されています🧩 (Firebase)

3) firebase.json を “配列” で書く🧾​

Multi-target JSON

{
  "hosting": [
    {
      "target": "staging",
      "public": "dist"
    },
    {
      "target": "prod",
      "public": "dist"
    }
  ]
}

4) デプロイを「ターゲット指定」で打つ🚀​

## stagingサイトだけに出す
firebase deploy --only hosting:staging

## prodサイトだけに出す
firebase deploy --only hosting:prod

この --only hosting:TARGET_NAME 形式も公式に明記されています✅（しかも更新日が 2026-02-03！） (Firebase)

AIで“事故防止”を加速する🤖🧯（ここが今っぽい！）​

1) コンソール内で詰まりを即解決：Gemini in Firebase🧠✨​

「staging/prodどう分ける？」「この設定で危なくない？」を、コンソールから相談できます🧯 セットアップ手順も公式にあります🧩 (Firebase)

2) Antigravity / Gemini CLI を “Firebase操作モード” にする：Firebase MCP server🧩🤝​

Firebase MCP server を入れると、AI開発ツール（Gemini CLI など）から Firebaseプロジェクトや設定を自然文で扱いやすくなります🔥 (Firebase) 「今どのプロジェクトに向いてる？」「deploy target一覧出して」みたいな確認が、事故防止にめちゃ効きます😆🧯

3) “リリース前チェック”をAIでテンプレ化：Firebase AI Logic / Genkit🧰🤖​

AI Release Check

この章はデプロイ運用の話ですが、実務っぽくするなら

  • 「本番デプロイ前にチェックリストをAIに作らせる」✅
  • 「PR本文から確認項目を自動生成する」📝 みたいなことを Firebase AI Logic（Gemini/Imagenを安全に呼ぶ）で作れます🔥 (Firebase)

ミニ課題🎒✨（15〜30分）​

Assignment

  1. ブランチ戦略を決める🌿

    • 例：main=prod / develop=staging

  2. PRプレビューが staging側 で出ることを確認する🔎

  3. “事故防止ルール”を1枚メモにする📝

    • 例：「本番は main からしか出さない」「Secretsは環境別」「PRプレビューはstagingだけ」など

チェック✅（できたら勝ち！🏆）​

Final Check

  • 「環境（staging/prod）」と「preview channel」の違いを説明できる🙂
  • develop → staging / main → prod が自動で出る🤖
  • PRプレビューが 本番ではなくstaging で動いている🔎
  • Secretsが環境別で分かれている🔐
  • デプロイ先を間違えない仕組み（project/target指定）がある🧯 (Firebase)

次の章（第15章：App Hosting入門）に行くと、SSR/フルスタック側でも同じ発想で 環境を作る話にスムーズに繋がります🧩🚀 (Firebase)