我正在考虑使用Firebase作为MBaaS,但是我找不到任何可靠的解决方案来解决以下问题:

我想建立两个独立的Firebase环境,一个用于开发,一个用于生产,但我不想手动复制功能(例如。开发和生产环境之间的远程配置设置、通知规则等)。

有什么我可以依赖的工具或方法吗?从头开始设置远程配置或通知规则可能是一项艰巨的任务,风险太大。

有什么建议吗?有没有比拥有两个独立环境更好的方法呢?

在你发表另一个解释如何建立独立Firebase帐户的问题答案之前:这不是问题,再读一遍。问题是:如何在独立的开发帐户和prod帐户之间转移更改或任何比在它们之间手动复制更好的解决方案。


当前回答

我们选择在本地开发服务器上为Test和UAT启动新的Firebase模拟器实例,完全不考虑GCP。它正是为这个用例设计的。

https://firebase.google.com/docs/emulator-suite

其他回答

您将需要管理不同的构建类型

遵循这个

首先,在Firebase控制台创建一个新项目,名称id为YOURAPPNAME-DEV 点击“添加android应用程序”按钮,创建一个新的应用程序。例如将其命名为com.yourapp.debug。新的谷歌服务。Json文件将 自动下载 在你的项目src目录下创建名为“debug”的新目录并复制新的google-services。Json文件 在模块级别构建中。Gradle添加这个 调试{ applicationIdSuffix“.debug” }

现在,当你构建一个调试构建谷歌服务。Json从“调试”文件夹将被使用,当你将构建在发布模式谷歌服务。将考虑来自模块根目录的Json。

我们选择在本地开发服务器上为Test和UAT启动新的Firebase模拟器实例,完全不考虑GCP。它正是为这个用例设计的。

https://firebase.google.com/docs/emulator-suite

我目前没有使用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/ !味精/ firebase-talk / L7ajIJoHPcA / 7 dsnutdlyryj

我们的方法是为不同的环境创建不同的json键文件。我们已经使用了谷歌推荐的服务帐户特性,并且有一个开发文件和另一个用于生产

为了解决这个问题,我创建了三个Firebase项目,每个项目都有相同的Android项目(即相同的applicationId,而不使用其他人建议的applicationIdSuffix)。这导致了三项谷歌服务。json文件,我将其作为自定义环境变量存储在持续集成(CI)服务器中。对于构建的每个阶段(dev/staging/prod),我都使用了相应的google服务。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
# https://stackoverflow.com/questions/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/

我对这个解决方案很满意,因为它不依赖于构建。gradle的技巧,我认为太不透明,因此很难维持。例如,当我尝试使用applicationIdSuffix和不同的buildtype方法时,我发现当我尝试使用testBuildType切换构建类型时,我无法运行测试,甚至无法编译。Android似乎给了调试buildType特殊的属性,我无法检查理解。

从我的经验来看,CI脚本非常透明且易于维护。实际上,我所描述的方法是有效的:当我在模拟器上运行CI生成的每个apk时,Firebase控制台的“运行应用程序以验证安装”步骤从

检查应用程序是否与我们的服务器通信。您可能需要卸载并重新安装应用程序。

to:

恭喜你,你已经成功地将Firebase添加到你的应用程序!

因为我在模拟器中一个一个地启动了这三个应用程序。