【Firebase Hosting】GitHub Actionsを使ってデプロイを自動化する方法を実例で解説！(firebase init hosting:github)

「Webサイトの更新のたびに手動でfirebase deployを実行するのは面倒…」そう感じていませんか？

本記事では、Firebase Hostingを使用しているプロジェクトで、コードの変更をGitHubにプッシュするだけで、本番環境への反映（デプロイ）を自動化する方法を実例を交えてご紹介します。

本記事の核となるのは、GitHubが提供する強力なCI/CDサービス「GitHub Actions」と、Firebase CLIのfirebase init hosting:githubコマンドです。この連携により、面倒な設定ファイル作成の手間を大幅に削減し、高品質かつスピーディーなデプロイパイプラインを簡単に構築することができます。

GitHub Actionsとは何か？
GitHub Actionsを使ってデプロイを自動化する方法
実例で解説
自動デプロイのテスト
【補足】プルリク(PL)で自動デプロイを「n(NO)」にするとどうなるか？
1. ワークフローファイルを生成しない
2. nを選択する場合
GitHub Actionsワークフローファイル
GitHub Actionsのワークフローを削除する方法

GitHub Actionsとは何か？

GitHub Actionsは、GitHubが提供するCI/CD（継続的インテグレーション/継続的デリバリー）のための自動化プラットフォームです。

GitHub上でコードのプッシュやプルリクエストの作成など、特定のイベントが発生したときに、あらかじめ定義しておいた一連の作業を自動で実行してくれる仕組みです。

開発者が手動で行っていたビルド、テスト、デプロイといった作業を自動化することで、開発の効率化をすることができます。

プライベートリポジトリの場合、無料枠（通常2,000分/月）が適用されます。ビルドの実行時間を5分とすると、400回/月までが無料となります。

パブリックリポジトリであれば、実行時間は無制限で無料です。

※Firebase Hostingの場合は、デプロイ回数ではなく、デプロイ後のホスティング容量とデータ転送量10GBが無料枠となります。

ご参考

GitHub Actionsの詳しい解説は下記をご参考ください。

＞ GitHub ActionsやCI/CDとは何か？.github/workflowsやワークフローファイルの作成と削除方法を実例で解説

GitHub Actionsを使ってデプロイを自動化する方法

GitHub Actionsを使ってFirebase Hostingのデプロイを自動化するのは実はとても簡単です。

Firebase CLIの「firebase init hosting:github」コマンドを利用するだけで、必要な設定が自動で行われます。

ただし、前提条件として以下が終わっている必要があります。

前提条件

Firebaseプロジェクトが作成済み。(firebase init)
Git管理済み。（git init）
GitHubにリモートリポジトリがある。

実例で解説

Firebaseプロジェクトの作成と、Hostingの初期化

まずは、Firebaseのプロジェクトを作成し、ローカルの対象のプロジェクトディレクトリをFirebase Hosting用に初期化します。

firebase init

Firebase Hotingの使い方

Firebase CLIやHostingの使い方は下記をご参考ください。

＞【徹底解説】Firebase Hostingの使い方｜プロジェクト作成・アプリ登録・WEBサイトの公開と停止を実例で分かりやすく解説

Git管理のリポジトリにする

Firebaseのプロジェクトディレクトリができたら、以下のコマンドを実行し、Gitの管理対象のリポジトリとします。

git init

Gitの使い方

Gitでプロジェクトを管理する方法は以下をご参考ください。

＞【初心者向け】Gitの使い方や開発の流れをわかりやすく実例で解説！git initからgit mergeまで(初期化、ブランチ作成,マージ,ブランチ削除)

GitHubにリモートリポジトリを作成し連携する

次に、リモートリポジトリを作成し、ローカルと紐づけた後にgit pushで連携します。

GitHubの使い方

GitHubにリモートリポジトリを作成して、git pushする方法は下記をご参考ください。

＞【初心者向け】GitHubの使い方｜リモートレポジトリの作成とローカルとの連携方法を実例で解説(git remote add, git push｜リモートリポジトリとは何か？)

GitHubアカウントの承認

Firebase Hostingのプロジェクトディレクトリ移動し以下のコマンドを実行します。

firebase init hosting:github

以下のように表示されるので「Y」を入力します。

$ firebase init hosting:github

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  C:\Users\～

Before we get started, keep in mind:

  * You are initializing within an existing Firebase project directory

? Are you ready to proceed? (Y/n)

初期化するのはGitHub Actionsのワークフローだけ！

「You’re about to initialize a Firebase project in this directory」で「Firebaseプロジェクトを初期化しようとしている」、既存のディレクトリの初期化をしようとしているがいいか？と聞かれます。

firebase init hosting:github が「初期化」するのは、Firebase プロジェクト全体ではなく、GitHub Actions による自動デプロイの設定（ワークフロー）だけです。

Firebase経由でGitHubにアクセスするための承認を行います。

認証が完了すると、以下の画面が表示されます。

リモートレポジトリの選択

コマンドラインに以下のように表示されるので、対象となるリモートレポジトリを選択します。

user/repositoryの調べ方

ここで入力すべきuser/repositoryは、GitHubで対象のリモートリポジトリのページにアクセスしたときのURLに記載してあります。

以下のように表示されるので、https://github.com/以下の「your-username/your-repository-name」が入力内容に当たります。

https://github.com/your-username/your-repository-name

ビルドをワークフローに含めるか？

続いて、デプロイの前にビルドを含めるかどうかを入力します。

React, Vue, Next.js, AngularなどのなどのモダンなWebアプリケーションでは、公開用の静的ファイル（HTML, CSS, JavaScript）を作成するためにビルドが必要です。そのため、ほとんどの場合、Y (Yes) と答えるのが適切です。

ビルドが不要な場合は「n」を入力します。

選択	意味	補足
Y (Yes)	デプロイ前にビルドスクリプトを実行する。	推奨。静的なウェブサイトやビルドが必要なフレームワークを使用している場合に選択します。この後、ビルドコマンドを尋ねられます（例：`npm run build`）。
n (No)	デプロイ前にビルドスクリプトを実行しない。	非常にシンプルな静的HTMLファイルのみで、ビルドが全く不要な場合に選択します。

なお、「Y」を入力すると、ビルドの処理として実行するコマンドを入力する質問に移ります。

? What is the build script for your project? (e.g. npm run build)

一般的なコマンドは以下の通りです。

一般的なビルドコマンド

npm run build (NPMを使用している場合)
yarn build (Yarnを使用している場合)
pnpm run build (pnpmを使用している場合)

このコマンドが、自動生成されるGitHub Actionsのワークフローファイルに記述され、mainへのpushのたびに実行されるようになります。

プルリク（PL）で自動デプロイをするか？

次に「Pull Request (PR) がマージされたときに、本番環境 (live channel) に自動デプロイを設定しますか？」と聞かれます。

git pushで自動的ビルドを行うようにしたい場合は「Y」を入力します。

「Y」にすることで、PRが main ブランチにマージされた後、または main に直接プッシュされたときに、Firebase Hostingのライブチャンネル（本番環境）へ自動的にデプロイされます。

ライブチャネル（本番環境）と紐づくブランチの指定

上記で「Y」を選択すると「ライブチャネル（本番環境）と紐づくブランチ名」を聞かれます。

対象のブランチ名を入力します。

以下のように表示されます。

+  Created workflow file C:\Users\～\test-firebase-app\.github/workflows/firebase-hosting-merge.yml

i  Action required: Visit this URL to revoke authorization for the Firebase CLI GitHub OAuth App:

https://github.com/settings/connections/applications/89rertydftyuiuytre
github.com
i  Action required: Push any new workflow file(s) to your repo

+  Wrote configuration info to firebase.json
+  Wrote project information to .firebaserc

+  Firebase initialization complete!

ワークフローファイルをpushする

現時点ではまだGitHub Actionsの自動化は完了していません。

ローカルに自動生成されたワークフローファイルをリモートレポジトリにpushすることで、GitHubがディレクトリおよびファイルを見つけて自動化を行います。

git add .github/
git commit -m "GitHub Actions workflow files"
git push origin main

自動デプロイのテスト

GitHub Actionsの設定が完了したら、自動デプロイができるかテストを行います。

上部メニューで「Actions」を選択します。

すると、登録したワークフローが表示されます「GitHub Actions workflow files」。

黄色い丸がグルグルしている間は自動化処理の実行中（ここではビルド処理中）です。

完了すると緑色のチェックになります。

クリックするとJob名が表示されます。

以上でFirebaseとGitHub Actionsを連携させた自動デプロイは完了です。

ご参考

GitHub Actionsの自動化処理に関する詳しい手順は下記をご参考ください。

＞ GitHub ActionsやCI/CDとは何か？.github/workflowsやワークフローファイルの作成と削除方法を実例で解説

【補足】プルリク(PL)で自動デプロイを「n(NO)」にするとどうなるか？

ワークフローファイルを生成しない

後半の方の設定で「Pull Request (PR) がマージされたときに、本番環境 (live channel) に自動デプロイを設定しますか？」と聞かれます。

通常、git pushでビルドを自動化したいのであれば「Y」を入力します。

ですが、ここであえて「n」を選ぶ場合もあります。

「n」を選択した場合、それは mainブランチへのマージ（またはプッシュ）をトリガーとしたライブチャンネルへの自動デプロイを、現時点では設定しないという意味になります。

このため、GitHub Actionsのワークフローに必要なファイル（通常、.github/workflows/firebase-hosting-merge.yml など）を自動生成しません。

nを選択する場合

「n」を選択した場合、本番環境 (live channel) へのデプロイは、開発者がローカルで firebase deploy コマンドを手動で実行する必要があります。

ですが、GitHub Actions自体を拒否しているわけではありません。

例えば以下のような場合に「n」を選択します。

独自のデプロイロジックの適用

例えば、デプロイ前に、データベースのマイグレーションやキャッシュのクリアなど、Firebase Hostingデプロイアクションだけでは完結しない複雑な前処理が必要な場合。

他には、CLIが生成するシンプルなワークフローを使わず、独自のカスタムスクリプトやパイプラインを手動で.github/workflowsフォルダに記述したい場合など。

複数の環境への対応（例：ステージング環境）

対象のブランチをライブチャンネル（本番）ではなく、別のステージング（Staging）チャンネルにデプロイしたい場合。

この場合、N を選択してから、生成されたワークフローファイルを手動で編集して channelId: live の部分を channelId: staging などに変更します。

GitHub Actionsワークフローファイル

firebase init hosting:githubの設定が完了すると、「.github/workflows」というディレクトリが新設され、その中に「firebase-hosting-merge.yml」と「firebase-hosting-pull-request.yml」いうGitHub Actionsの設定が書かれたワークフローファイルが自動生成されます。

この２つは、トリガーとなるイベントとデプロイ先が異なります。

簡単に言うと、「firebase-hosting-merge.yml」はpushやプルリクでマージされたときに実行するビルド処理です。

「firebase-hosting-pull-request.yml」はプレビュー用のデプロイで、変更のレビューとテスト用です。

ファイル名	トリガーとなるGitHubイベント	デプロイ先	目的
`firebase-hosting-merge.yml`	`main` ブランチへの `push` (通常はPRのマージ時)	`live` チャンネル (本番環境)	承認されたコードを本番環境に公開すること
`firebase-hosting-pull-request.yml`	Pull Requestの `opened`、`synchronize`、または `reopened`	プレビューチャンネル (一時的なURL)	マージ前に変更内容をテスト・確認すること

GitHub Actionsのワークフローを削除する方法

ワークフローファイルを削除する

作成したGitHub Actions（ワークフロー）を削除する手順は、非常に簡単です。

ワークフローファイルをリモートリポジトリから削除すればOKです。

GitHub Actionsは、リポジトリの特定のディレクトリに配置されたYAMLファイル（ワークフローファイル）に基づいて動作するため、そのファイルがなくなれば、GitHubは自動的にそのワークフローを実行しなくなります。

コード例

具体的には以下のコードを実行します。

# ワークフローファイルへのパスを指定して削除
rm .github/workflows/～.yml

# 削除をステージングに追加
git add . 

# 変更をコミット
git commit -m "chore: Remove workflow"

#コミットをプッシュ
git push

GitHubの履歴を手動で削除

ファイルを削除しても、GitHubの「Actions」タブに残っている過去の実行ログは自動では消えません。

過去の実行ログは、手動で削除する必要があります。

（ただし、デフォルト設定の場合は、古い実行ログは一定期間が過ぎると自動的にGitHubによって削除されます）

もしすぐに実行ログを消したい場合は、GitHubのWeb UIから以下の手順で削除できます。

GitHubリポジトリのActionsタブへ移動します。
削除したいワークフロー名をクリックします。
削除したい実行を選択し、右上のメニュー（3点リーダーなど）から「Delete workflow run」を選びます。