個別の開発および本番Firebase環境

FirebaseをMBaaSとして使用することを検討していますが、次の問題に対する信頼できる解決策が見つかりませんでした。

開発用と本番用の2つの別々のFirebase環境をセットアップしたいのですが、開発環境と本番環境の間で機能（たとえば、リモート構成のセットアップ、通知ルールなど）を手動でコピーしたくありません。 。

信頼できるツールや方法はありますか？リモート構成または通知ルールを最初からセットアップすることは困難な作業であり、リスクが高すぎる可能性があります。

助言がありますか？2つの別々の環境を用意するよりも良い方法はありますか？

別のFirebaseアカウントを設定する方法を説明する質問に別の回答を投稿する前に、質問ではありません。もう一度読んでください。問題は、個別のdevアカウントとprodアカウントの間で変更を転送する方法、または手動でそれらの間でコピーするよりも優れたソリューションです。

誰もが指摘しているように、複数のプロジェクト/データベースが必要です。

ただし、設定/データなどを開発から本番にコピーできるようにする必要があるかどうかについての質問に答えるために。まったく同じニーズがありました。開発とテストの数か月間、データを手動でコピーしたくありませんでした。

私の結果は、データをストレージバケットにバックアップし、そこから他のデータベースに復元することでした。それはそれを行うにはかなり大雑把な方法です-そして私はデータベース全体のバックアップ/復元をしました-より制御された方法のためにその方向を見ることができるかもしれません。私はそれを使用していません-それは非常に新しいです-しかし、これは解決策かもしれません：NPMモジュールfirestore-export-import

編集：ここでFirestoreのバックアップ/エクスポート/インポート情報Cloud Firestoreデータのエクスポートとインポート

FirestoreではなくFirebase RTDBを使用している場合-このドキュメントが役立つ場合があります： Firebase Automated Backups

本番データベースが開発と同じストレージバケットにアクセスできるように、権限を正しく設定する必要があります。幸運を。

firebase-tools firebase useを使用している場合は、使用しているプロジェクトを設定できるコマンドがありますfirebase deploy

firebase use --addプロジェクトのリストが表示されるので、プロジェクトを選択すると、エイリアスの入力を求められます。そこから次のことが可能firebase use aliasとfirebase deploy、そのプロジェクトにプッシュします。

私の個人的な使用では、Firebaseコンソールのプロジェクトとしてmy-appとmy-app-devがあります。

私は現在Firebaseを使用していませんが、あなたと同じように考えています。行く方法は、コンソール上で完全に別のプロジェクトを作成することです。古いFirebaseサイトでこれを推奨するブログ投稿がありましたが、現在は削除される予定です。 https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html

このディスカッションでも同じことを推奨しています：https : //groups.google.com/forum/#!msg / firebase-talk / L7ajIJoHPcA / 7dsNUTDlyRYJ

私がやった方法：

1. 私は2つのプロジェクトをfirebaseに持っていました-1つはDEV用、もう1つはPROD用
2. ローカルには私のアプリにも2つのブランチがありました-1つはDEVという名前で、もう1つはPRODという名前です
3. 私のDEVブランチには常にDEV firebaseプロジェクトのJSONファイルがあり、PRODの場合も同様です

この方法では、JSONを維持する必要はありません。

このブログ記事では、デバッグとリリースのビルドタイプを使用した非常にシンプルなアプローチについて説明します。

一言で言えば：

• 異なるアプリケーションIDサフィックスを使用して、ビルドタイプごとにFirebaseで新しいアプリを作成します。
• 最新のJSONファイルを使用してAndroidプロジェクトを構成します。
• applicationIdSuffixを使用して、ビルドタイプに応じてFirebase上のさまざまなアプリに一致するようにアプリケーションIDを変更します。

=>詳細な説明については、ブログ投稿を参照してください。

別のビルドフレーバーを使用する場合は、Firebaseの公式ブログからこの広範なブログ投稿をご覧ください。貴重な情報がたくさん含まれています。

お役に立てば幸いです。

異なるビルドタイプを管理する必要があります

これに従ってください

1. まず、Firebase consoleで新しいプロジェクトを作成し、IDにYOURAPPNAME-DEVと名前を付けます。

2. [Androidアプリを追加]ボタンをクリックして、新しいアプリを作成します。たとえば、com.yourapp.debugという名前を付けます。新しいgoogle-services.jsonファイルが自動的にダウンロードされます

3. プロジェクトのsrcディレクトリの下に、「debug」という名前の新しいディレクトリを作成し、新しいgoogle-services.jsonファイルをここにコピーします

4. あなたのモジュールレベルのbuild.gradleにこれを追加してください

   debug {
           applicationIdSuffix ".debug"
       }
   

ここで、デバッグビルドをビルドするとき、「デバッグ」フォルダーからgoogle-services.jsonが使用され、リリースモードでビルドするとき、モジュールのルートディレクトリからgoogle-services.jsonが考慮されます。

私の状況でこれを解決するために、3つのFirebaseプロジェクトを作成しました。それぞれが同じAndroidプロジェクトapplicationIdを使用しています（つまりapplicationIdSuffix、他の人が提案したものを使用せずに同じです）。これにより、継続的インテグレーション（CI）サーバーにカスタム環境変数として保存した3つのgoogle-services.jsonファイルが生成されました。ビルドの各ステージ（dev / staging / prod）で、対応するgoogle-services.jsonファイルを使用しました。

devに関連付けられているFirebaseプロジェクトのAndroidプロジェクトに、デバッグSHA証明書のフィンガープリントを追加しました。ただし、ステージングと製品版では、CIにAPKに署名するだけです。

以下は、.gitlab-ci.ymlこの設定で機能する簡単なものです。

# This is a Gitlab Continuous Integration (CI) Pipeline definition
# Environment variables:
#   - variables prefixed CI_ are Gitlab predefined environment variables (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
#   - variables prefixed GNDR_CI are Gitlab custom environment variables (https://docs.gitlab.com/ee/ci/variables/#creating-a-custom-environment-variable)
#
# We have three Firebase projects (dev, staging, prod) where the same package name is used across all of them but the
# debug signing certificate is only provided for the dev one (later if there are other developers, they can have their
# own Firebase project that's equivalent to the dev one).  The staging and prod Firebase projects use real certificate
# signing so we don't need to enter a Debug signing certificate for them.  We don't check the google-services.json into
# the repository.  Instead it's provided at build time either on the developer's machine or by the Gitlab CI server
# which injects it via custom environment variables.  That way the google-services.json can reside in the default
# location, the projects's app directory.  The .gitlab-ci.yml is configured to copy the dev, staging, and prod equivalents
# of the google-servies.json file into that default location.
#
# References:
# https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html
# /programming/57129588/how-to-setup-firebase-for-multi-stage-release

stages:
  - stg_build_dev
  - stg_build_staging
  - stg_build_prod

jb_build_dev:
  stage: stg_build_dev
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_DEV_FILE} app/google-services.json
    - ./gradlew :app:assembleDebug
  artifacts:
    paths:
      - app/build/outputs/apk/

jb_build_staging:
  stage: stg_build_staging
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  dependencies: []
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_STAGING_FILE} app/google-services.json
    - ./gradlew :app:assembleDebug
  artifacts:
    paths:
      - app/build/outputs/apk/

jb_build_prod:
  stage: stg_build_prod
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  dependencies: []
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_PROD_FILE} app/google-services.json

    # GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED created on Mac via:
    # base64 --input ~/Desktop/gendr.keystore --output ~/Desktop/keystore_base64_encoded.txt
    # Then the contents of keystore_base64_encoded.txt were copied and pasted as a Gitlab custom environment variable
    # For more info see http://android.jlelse.eu/android-gitlab-ci-cd-sign-deploy-3ad66a8f24bf
    - cat ${GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED} | base64 --decode > gendr.keystore

    - ./gradlew :app:assembleRelease
      -Pandroid.injected.signing.store.file=$(pwd)/gendr.keystore
      -Pandroid.injected.signing.store.password=${GNDR_CI_KEYSTORE_PASSWORD}
      -Pandroid.injected.signing.key.alias=${GNDR_CI_KEY_ALIAS}
      -Pandroid.injected.signing.key.password=${GNDR_CI_KEY_PASSWORD}
  artifacts:
    paths:
      - app/build/outputs/apk/

私がこのソリューションに満足しているのは、あまりにも不透明でメンテナンスが難しいと思うbuild.gradleのトリックに依存していないためです。たとえばapplicationIdSuffix、さまざまなを使用してアプローチを試したところ、を使用してbuildTypeビルドタイプを切り替えようとしたときに、インストルメント化されたテストを実行したり、コンパイルしたりすることができないことがわかりましたtestBuildType。Androidは、debug buildType私が理解するために検査することができなかったものに特別な特性を与えるように見えました。

好意的には、CIスクリプトは非常に透過的であり、私の経験ではメンテナンスが簡単です。実際、私が説明したアプローチは機能しました。CIによって生成された各APKをエミュレータで実行すると、Firebaseコンソールの「アプリを実行してインストールを確認する」ステップが

アプリがサーバーと通信しているかどうかを確認しています。アプリをアンインストールして再インストールする必要がある場合があります。

に：

おめでとうございます。Firebaseがアプリに正常に追加されました。

3つのアプリすべてをエミュレータで1つずつ起動したところです。

Firebaseには、このページがあり、開発者と製品向けに設定する方法を説明しています。

https://firebase.google.com/docs/functions/config-env

プロジェクトの環境構成を設定する環境データを保存するには、Firebase CLIでfirebase functions：config：setコマンドを使用できます。ピリオドを使用して各キーに名前空間を設定し、関連する構成をグループ化できます。キーには小文字しか使用できないことに注意してください。大文字は使用できません。

たとえば、「Some Service」のクライアントIDとAPIキーを保存するには、次を実行します。

firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"

現在の環境設定の取得プロジェクトの環境設定に現在保存されているものを検査するには、firebase functions：config：getを使用できます。次のようなJSONを出力します。

{
  "someservice": {
    "key":"THE API KEY",
    "id":"THE CLIENT ID"
  }
}

私が見つけた情報に基づいて、この回答を更新しています。

ステップ1

firebase.google.comで、複数の環境（つまり、開発、ステージング、製品）を作成します

mysite-dev

マイサイトのステージング

mysite-prod

ステップ2

a。デフォルトにしたい直接（つまり、dev）に移動します

b。走るfirebase deploy

c。デプロイしたら、実行しますfirebase use --add

d。現在持っているさまざまなプロジェクトから選択するオプションが表示されます。

追加するプロジェクトmysite-stagingまでスクロールして、選択します。

e。次に、そのプロジェクトのエイリアスを要求されます。ステージングを入力します。

各環境がエイリアスを持つように、prodとdevに対してアイテムaeを再度実行します。

現在の環境を把握する

走る firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

（環境の1つには、その左側にアスタリスクがあります。これは現在使用している環境です。また、青色で強調表示されます）

環境を切り替える

実行firebase use stagingまたはfirebase use prodそれらの間を移動します。

必要な環境になったら、実行するfirebase deployとプロジェクトがそこにデプロイされます。

ここにいくつかの役立つリンクがあります...

CLIリファレンス

複数の環境への展開

お役に立てれば。

これを行う方法は、さまざまな環境に応じてさまざまなjsonキーファイルを作成することです。Googleが推奨するサービスアカウント機能を使用しており、開発用に1つの開発ファイルと本番用にもう1つあります

FirebaseにDevと本番環境でTowプロジェクトを作成します。

SDKを次のようにセットアップします。https：//firebase.google.com/docs/android/setupまたはCrashlyticsの場合：https ://firebase.google.com/docs/crashlytics/get-started ? platform=android

最初に、各buildTypeに対応するgoogle_services.jsonを次の場所に配置します。

app/src/debug/google_services.json
app/src/test/google_services.json
app/google_services.json

注：ルートapp / google_services.jsonこのファイルは、ビルドバリアントに従って存在する必要があります。ルートjsonファイルにjsonコードをコピーします

次に、適切なgoogle_services.jsonをapp / google_services.jsonに自動的に移動するために、アプリのbuild.gradleにいくつかのGradleタスクを作成します。

これをapp / Gradleファイルにコピーします

task switchToDebug(type: Copy) {
description = 'Switches to DEBUG google-services.json'
from "src/debug"
include "google-services.json"
into "."
}

task switchToRelease(type: Copy) {
description = 'Switches to RELEASE google-services.json'
from "src/release"
include "google-services.json"
into "."
}

すばらしい—ただし、アプリをビルドする前にこれらのタスクを手動で実行する必要があるのは面倒です。上記の適切なコピータスクを実行する前に実行する必要があります。つまり、assembleDebugまたは：assembleReleaseが実行されます。：assembleReleaseを実行するとどうなるか見てみましょう：これを/ gradlewファイルにコピーします

Zaks-MBP:my_awesome_application zak$ ./gradlew assembleRelease
Parallel execution is an incubating feature.
.... (other tasks)
:app:processReleaseGoogleServices
....
:app:assembleRelease

：app：processReleaseGoogleServicesタスクに注目してください。このタスクは、ルートgoogle_services.jsonファイルの処理を担当します。正しいgoogle_services.jsonが処理されるようにするため、事前にコピータスクをすぐに実行する必要があります。これをbuild.gradleに追加します。囲んでいるafterEvaluateに注意してください。

これをapp / Gradleファイルにコピーします

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

これで、：app：processReleaseGoogleServicesが呼び出されると、新しく定義された：app：switchToReleaseが事前に呼び出されます。デバッグ用buildTypeと同じロジック。：app：assembleReleaseを実行すると、リリースバージョンgoogle_services.jsonがアプリモジュールのルートフォルダに自動的にコピーされます。