コードベースから複数の環境をデプロイする

同じコードベースから複数の環境をデプロイし、それぞれ構成が若干異なることはよくあります。たとえば、ステージング環境に割り当てる CPU と RAM を少なくしたり、本番環境で少なくとも 1 つのインスタンスをアクティブにしてリクエストを処理できるようにしたりすることが考えられます。また、使用する環境やリソースに応じて、異なる環境変数やシークレットを指定することもできます。

このガイドでは、本番環境とステージング環境をそれぞれ別の Firebase プロジェクトにデプロイする方法について説明します。同じ原則に従って、他の種類の環境にデプロイすることもできます。環境の詳細については、環境の概要と Firebase プロジェクトの設定に関する一般的な効果的な手法をご覧ください。

前提条件

アプリケーションコードがすでに GitHub に保存されている。
環境ごとに個別のプロジェクト（my-production-firebase-project や my-staging-firebase-project など）をすでに作成している。本番環境の Firebase プロジェクトに "本番環境" 環境タイプのタグを付けてください。
各プロジェクトで、App Hosting バックエンドを作成し、ライブブランチをデプロイする GitHub ブランチ（main など）に設定している。詳細については、 App Hostingを使ってみるをご覧ください。

ステップ 0: apphosting.yaml でデフォルト構成を作成する

App Hosting は、apphosting.yaml という構成ファイルをサポートしています。このファイルを使用して、アプリのランタイム設定（CPU、同時実行、メモリ上限など）と環境変数を管理できます。また、Cloud Secret Manager で管理されるシークレットへの参照もサポートしているため、ソース管理に安全にチェックインできます。詳細については、バックエンドを構成するをご覧ください。

まず、アプリのルートディレクトリに apphosting.yaml ファイルを作成します。これは、環境固有の構成ファイルが見つからない場合に使用されるフォールバック構成ファイルです。apphosting.yaml に保存される値は、すべての環境で安全に使用できるデフォルト値にする必要があります。

次のセクションでは、特定の環境で apphosting.yaml のデフォルト値をオーバーライドする方法について説明します。この例では、ステージング環境を作成します。

ステップ 1: 環境名を設定する

各 App Hosting バックエンドには、[環境名] 設定があります。このフィールドは、バックエンドを環境固有の構成ファイルにマッピングするために使用され、いつでも変更できます。バックエンドごとに設定できる環境名は 1 つだけです。

バックエンドの環境名を設定するには:

Firebase コンソールで、ステージングプロジェクト（この例では my-staging-firebase-project）を選択します。
[Hosting &Serverless] > [App Hosting] に移動します。
選択したバックエンドで [ダッシュボードを表示] をクリックします。
[設定] タブで、[環境] を選択します。
[環境名] に、環境の名前を入力します。環境の名前は自由に設定できます。この例では、staging です。
[保存] をクリックします。

バックエンドの App Hosting ロールアウトがトリガーされると（git push 時または Firebase コンソールから手動で）、App Hosting は apphosting.yaml にフォールバックする前に apphosting.ENVIRONMENT_NAME.yaml ファイルを確認します。

ステップ 2: 環境固有の `apphosting.yaml` ファイルを作成する

環境固有の構成の場合は、環境固有のオーバーライドを指定するために、 apphosting.ENVIRONMENT_NAME.yaml という名前のファイルを作成します。このファイルはデフォルトのapphosting.yamlと同じ形式で、アプリのルートディレクトリに apphosting.yamlとともに配置する必要があります。

ビルド時に、App Hosting はこれら 2 つのファイルをマージします。環境固有の YAML ファイルの値が基本の apphosting.yaml ファイルよりも優先されます。

この例では、アプリのルートディレクトリに apphosting.staging.yaml という名前のファイルを作成します。


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

次のような apphosting.yaml がすでに存在するとします。

runConfig:
  cpu: 3
  memoryMiB: 1024
  maxInstances: 4
  minInstances: 0
  concurrency: 100

env:
-   variable: API_URL
    value: api.service.com
    availability:
      -   BUILD
      -   RUNTIME

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

最終的にマージされた出力は次のようになります。これは Cloud Build ログで確認できます。

runConfig:
  cpu: 1
  memoryMiB: 512
  maxInstances: 4
  minInstances: 0
  concurrency: 5

env:
-   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      -   RUNTIME

-   variable: API_KEY
    secret: secretIDforAPI

-   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

CPU などの特定の runConfig 値と、重複する環境変数が上書きされています。

ステップ 3: コードベースをデプロイする

環境固有の apphosting.ENVIRONMENT_NAME.yaml ファイルの編集が完了したら、ファイルを GitHub に push します。

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

この環境名でタグ付けされたバックエンドは、対応する YAML ファイルで指定した特定のオーバーライド値を使用し、値が見つからない場合は apphosting.yaml にフォールバックします。関連付けられた環境名がないバックエンドの場合は、引き続き apphosting.yaml を使用できます。

次のステップ

詳細を確認する: ホストされているアプリを Firebase Authentication と Google AI 機能に統合する Firebase Codelab を確認する: Next.js | Angular
カスタムドメインを接続する。
バックエンドを構成する。
ロールアウト、サイトの利用状況、ログをモニタリングする。