自動ロールアウトを有効にしている場合、GitHub リポジトリのライブブランチに新しい commit を push するたびに、App Hosting によってアプリの新しいバージョンが自動的にロールアウトされます。ロールアウトのステータスは、Firebase コンソールまたは App Hosting GitHub チェックで確認できます。
また、App Hosting は、CI/CD 統合や、ロールアウトを強制的に実行する場合など、手動でトリガーされるロールアウトをサポートしています。
ロールアウトを表示する
Firebase コンソールでは、アプリのすべてのロールアウトに関する詳細情報にアクセスできます。
[ホスティングとサーバーレス] > [アプリ ホスティング] に移動し、ロールアウトを表示するバックエンドの [表示] を選択します。バックエンドの [ロールアウト] タブには、このバックエンドのすべてのロールアウトの履歴を一覧表示するテーブルが表示されます。
各ロールアウト エントリには、Cloud Build ジョブと、ロールアウトをトリガーした変更または commit へのリンクが含まれています。また、ロールアウトの作成者、作成日、ステータスに関する基本情報も含まれています。
- Cloud Build ジョブは、App Hosting がアプリのビルドコマンドを実行するビルド環境です。ビルド ID をクリックすると、Cloud Build ログにアクセスできます。
- 変更は、ロールアウトをトリガーした GitHub commit またはその他のアクションです。
ロールアウトを手動でトリガーする
新しい commit を push することなく GitHub ソースからロールアウトを手動でトリガーする場合は、Firebase コンソールまたは Firebase CLI からロールアウトを作成できます。これは、次のような場合に役立ちます。
- 静的コンテンツの再生成を強制します。
- CI/CD システムがロールアウトをトリガーできるようにします。
- 本番環境のロールアウトを特定の日付または時間に制限する。
Firebase コンソールでロールアウトをトリガーするには:
- Firebase コンソールで、[Hosting & Serverless] > [App Hosting] に移動します。
- ロールアウトを作成するバックエンドの [表示] をクリックします。
- バックエンド ダッシュボードの概要で、[ロールアウトを作成] を選択します。
- デプロイするブランチを選択します。
- デプロイする commit を選択します。最新の commit または commit ID で指定された以前の commit を選択できます。
- [作成] を選択します。ロールアウトのステータスとビルド番号がロールアウト履歴テーブルに表示されます。ロールアウト プロセスが完了すると、このロールアウトが現在のロールアウトとして表示されます。
Firebase CLI でロールアウトをトリガーするには、次のコマンドを実行し、プロンプトが表示されたらロールアウトのブランチを選択します。
firebase apphosting:rollouts:create BACKEND_ID
または、--git-branch オプションを使用して、特定のブランチの最新の commit のロールアウトを開始することもできます。
firebase apphosting:rollouts:create BACKEND_ID
--git_branch BRANCH_NAME
--git-commit オプションを使用して、特定のコミットでロールアウトを作成することもできます。
firebase apphosting:rollouts:create BACKEND_ID
--git_commit COMMIT_ID
以前のロールアウトを復元する
App Hosting には、以前のロールアウトを復元するための 2 つのオプションがあります。
- 再構築せずにすぐにロールバック
- 以前のバージョンに再構築してロールバックする
インスタント ロールバックを作成する
アプリの古いバージョンにすばやく戻す必要がある場合があります。たとえば、新たにデプロイしたロールアウトで重大なバグが見つかった場合や、新しいロールアウトを妨げる不安定なビルドが発生している場合などです。このような場合は、以前のロールアウトから既存のコンテナ イメージを復元できます。このイメージは再ビルドされませんが、最初にビルドされたときのコードと環境構成が使用されます。
インスタント ロールバックを作成するには:
- Firebase コンソールで、[Hosting & Serverless] > [App Hosting] に移動します。
- ロールバックを作成するバックエンドの [表示] をクリックします。
- [ロールアウト] タブを選択します。
- バックエンドの [履歴] テーブルで、以前のビルドのその他メニューを選択します。
- [このビルドにロールバックする] を選択して、確認します。
再構築とロールバック
アプリの古いバージョンに戻し、現在の構成を維持する場合は、ロールバック プロセスの一環としてアプリを再ビルドできます。たとえば、最新バージョンで Secret Manager の API キー値が更新された場合、再ビルドを行うことで、ロールバック後にアプリで新しいキーが使用されるようになります。
再ビルドしてロールバックするには:
- Firebase コンソールで、[Hosting & Serverless] > [App Hosting] に移動します。
- ロールバックを作成するバックエンドの [ダッシュボードを表示] をクリックします。
- [ロールアウト] タブを選択します。
- [ロールアウトを作成] を選択します。
- [ロールアウトを作成] ダイアログで、[以前の commit] を選択し、再ビルドしてロールバックするバージョンの commit ID を入力します。コミット ID は、ロールアウト履歴に表示される各ロールアウトの [変更の詳細] の一部であり、ラベルの括弧内に含まれています。
- [作成] を選択して、ロールバックを開始します。
ロールアウトの設定を変更する
ロールアウトのライブブランチを変更したり、バックエンドのダッシュボードの [設定 > デプロイ] ビューのコントロールを使用して自動ロールアウトを無効または有効にしたりできます。
- Firebase コンソールで、[Hosting & Serverless] > [App Hosting] に移動します。
- ロールアウト設定を更新するバックエンドの [表示] をクリックします。
- バックエンド ダッシュボードで、[設定] を選択します。デフォルトのビューには、ドメインとカスタム ドメインに関する情報が表示されます。
- [Deployment] ビューを選択します。このビューでは、ロールアウトのライブブランチを変更したり、自動ロールアウトを無効または有効にしたりできます。また、アプリのルート ディレクトリとバックエンドの環境を設定するオプションもあります（複数の環境にデプロイするをご覧ください）。
自動ロールアウトを管理する
デフォルトでは、App Hosting はすべてのファイルの「必須」リストを想定しています。つまり、リポジトリへの新しいコミットごとに、新しいビルドとロールアウトがトリガーされます。ただし、時間を節約し、不要なデプロイを防ぐために、コミットで変更された特定のファイルパスに基づいてビルドをスキップするように App Hosting を構成できます。
この設定は、[設定] > [ロールアウト] > [ロールアウト トリガー] で構成できます。ここで、リポジトリへの新しいコミットごとに新しいビルドとロールアウトをトリガーする場合は、[Required Paths] を空白のままにします。ロールアウトを常にトリガーするディレクトリまたはファイルを正確に指定することもできます。ディレクトリを指定する場合は、変更によってロールアウトがトリガーされるすべてのパスを追加してください。
[無視するパス] に追加したディレクトリまたはファイルからは、自動ロールアウトはトリガーされません。サブディレクトリが必須リストと無視するリストの両方に該当する場合、自動ロールアウトはトリガーされません。無視するパスのリストのみを入力すると、App Hosting は必須パスに「*」を自動的に入力します。
変更されたファイルが必要なパスと一致しない commit を push した場合（または、無視されたパスによってすべての変更が明示的に除外されている場合）、App Hosting は GitHub イベントの受信を確認しますが、ビルドとロールアウトの状態を SKIPPED としてマークし、自動ロールアウトはトリガーされません。