第08章：本番（live）自動デプロイ（マージで反映）🚢
この章は 「PRでプレビュー確認 → マージしたら本番URLが自動で更新」 を完成させる回です！ “世に出す” 感が一気に出ます😆🌍
1) まずイメージをつかもう🧠🔁
PRのとき（プレビュー）🧪
- PRを作る → プレビューURL ができる
- そこで動作確認＆レビューできる👀✨ （※プレビューも本番も、基本は “実在のバックエンド資源” を触り得るので、やらかし防止は意識しようね⚠️）(Firebase)
マージしたとき（本番 live）🚀
- PRを main（または master）にマージ
- すると main に push が発生
- その push をトリガーに GitHub Actions が動いて、live へデプロイ 🎉 「マージ＝本番反映」まで自動化されます🤖(Firebase)
2) 手を動かす🛠️🔥（“マージでlive反映”を完成させる）
Step 0：まずは「本番デプロイ用ワークフロー」があるか確認👀
リポジトリのここ👇を見てね：
.github/workflows/
だいたい、以下みたいな “merge / prod / live” 系の yml が入ってます（CLIが作ることも多い）(Firebase)
ポイントは2つ👇
on: pushでbranches: [main]（main に push されたら走る）FirebaseExtended/action-hosting-deployでchannelId: live（liveへ出す）(GitHub)
Step 1：CIの Node.js は「24 LTS」を基準にしよう🟩
2026年2月時点だと Node 24 が Active LTS です。(nodejs.org) さらに GitHub 側も runnerの既定Nodeが 2026-03-04 から Node24 へ寄る 動きがあるので、ワークフローでバージョン固定しておくのが安心です🧷(The GitHub Blog)
Step 2：本番デプロイ用 workflow（例）📄
あなたの yml がすでにあるなら「確認＆調整」が中心。無いなら、雰囲気はこう👇 （※コードブロックは例だよ。手元の構成に合わせてね）
name: Deploy to Live Channel
on:
push:
branches:
- main
jobs:
deploy_live:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v6
with:
node-version: 24
cache: npm
- run: npm ci
- run: npm run build
- uses: FirebaseExtended/action-hosting-deploy@v0
with:
firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
projectId: your-firebase-project-id
channelId: live
この形の“根拠”は、Actionの公式READMEに 「push to main で live に出す例」 が明記されてます。(GitHub)
Step 3：Secrets（鍵）が入ってるか確認🔐
FIREBASE_SERVICE_ACCOUNT は サービスアカウントJSONキー で、GitHubの Encrypted Secrets に入れて使います。
（漏れると普通に危険😇）(GitHub)
ここが無い／名前が違うと、ほぼ確実に本番デプロイが落ちます💥
Step 4：実際に「PR→マージ→本番更新」を回す🔁🚢
Windows での流れはこんな感じ（GitHub操作でもOK）👇
- ちょい変更を入れる（例：ヘッダー文言を変える）✏️
- PRを作る → プレビューURLで確認👀
- PRを main にマージ🎯
- GitHub の Actions タブで “Deploy to Live” が走るのを確認🏃♂️💨
- 本番URLをリロードして反映確認🌐✨
ローカルからやるなら例👇
git checkout -b feature/live-banner
## 何か1行だけUI変更する（src/App.tsx とか）
git add .
git commit -m "Update banner text"
git push -u origin feature/live-banner
3) 反映できたか確認するコツ✅📸
いちばん確実なのは「見た目でわかる差分」を入れる👀
- 例：ページ上部に「v1」「v2」みたいな文字を一瞬入れる
- マージ前（プレビュー）と、マージ後（本番）の スクショ比較 が強い📸✨
もう一段ちゃんと見るなら
- GitHub Actions のログで「デプロイ完了」まで到達しているか確認🧾
- Firebase Hosting 側の “リリース履歴” で更新時刻を見る（UIで確認）⌚
4) よくある詰まりポイント集🧯（初心者がハマりがち）
❌ 「Actionsは成功なのに、本番の表示が変わらない」
- ビルド成果物の置き場所 と
firebase.jsonのpublic（または設定）がズレてる可能性大📦🌀 - 「ビルドして生成されるフォルダ（例：
distやbuild）」が、Hostingが配る対象になってるか確認しよう
❌ 「Secretsがない/名前違いでコケる」
FIREBASE_SERVICE_ACCOUNTの名前がズレてると即死しがち💥(GitHub)
❌ 「mainじゃなくてmaster運用」
- workflow の
branches:が 今の運用ブランチ名 と一致してないと発火しないよ⚠️
❌ 「モノレポで関係ない変更でも毎回デプロイされる」
paths:で絞ると気持ちいい😌
on:
push:
branches: [main]
paths:
- "web/**"
- ".github/workflows/**"
5) AIで“詰まり”を即解決🤖🧯（この章のうま味ポイント）
A) Antigravity × Firebase MCP：デプロイ作業をAIに寄せられる🧩🚀
Antigravity は Firebase MCP server を使って、Hosting へのデプロイ計画→実行まで支援できます（firebase deploy --only hosting を含む流れをAIが案内）(The Firebase Blog)
使い方イメージ（プロンプト例）💬✨
- 「PRをマージしたらliveに出るはず。GitHub Actionsのymlを見て、発火条件とデプロイ先が正しいか点検して」
- 「
channelId: liveになってる？ Secrets名は合ってる？」(GitHub)
B) Gemini in Firebase：コンソール内で“詰まり相談”できる🧠💡
Firebase コンソール右上の ✦ から Gemini ペインを開いて相談できます。(Firebase) （エラー文を貼って「原因候補→次の確認手順」を出させるのが強い💪）
C) Gemini CLI：Firebase拡張（MCP）で調査を寄せる🔎💻
Firebase MCP server は Gemini CLI とも相性よく作られてる ので、CLI上での調査・操作がやりやすいです。(Firebase)
6) ミニ課題🎯（10〜20分）
課題：PR→マージ→本番反映を“証拠付き”で完了しよう📸✅
- 画面のどこかに「Hello Live v1」みたいな表示を追加✍️
- PR作成 → プレビューURLで表示確認👀
- mainへマージ🚢
- Actions成功ログを確認🧾
- 本番URLで「Hello Live v1」が出るスクショ撮影📸
- PR画面に “証拠” としてスクショ貼る（自分用メモでOK）📝
7) チェック✅（できたら合格！）
- PRでプレビューURLを見れて、変更が確認できた👀
- マージ後に GitHub Actions が push(main) で動いた🏃♂️(GitHub)
- live（本番URL）が更新された🌍✨
-
FIREBASE_SERVICE_ACCOUNTが Secrets に入っていて、漏らしちゃいけない理解がある🔐(GitHub) - （できれば）“見た目でわかる差分”＋スクショで証拠が残せた📸
次の第9章は「Secrets・権限・事故防止」をガッツリ固める回だけど、 第8章が回るだけで “自動リリース体験”が一気に現実になります 😎🚢✨