单独的dev和prod Firebase环境

rac*_*acs 120 firebase

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

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

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

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

在您发布解释如何设置单独的Firebase帐户的问题的另一个答案之前:这不是问题,请再次阅读.问题是:如何在单独的dev和prod帐户之间转换更改,或者比在它们之间手动复制更好的解决方案.

Lun*_*box 49

如果您使用的是firebase-tools,则可以使用一个命令firebase use来设置您正在使用的项目firebase deploy

firebase use --add将显示您的项目列表,选择一个,它会要求您提供别名.从那里,你可以firebase use aliasfirebase deploy将推动该项目.

在我个人的使用中,我将my-app和my-app-dev作为Firebase控制台中的项目.

  • 据我了解,Firebase 工具对于部署托管文件和数据库很有用,但它对数据库、分析或远程配置没有任何作用。或者我错过了什么? (2认同)

Pat*_*ick 24

我目前没有使用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

  • 另请阅读:https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html (3认同)
  • 谢谢你的回答.有两个单独的项目很可能是唯一的选择.但是,在它们之间复制数据至多是复杂的.我想知道Firebase工具是否可以复制规则,受众设置等.在我看来它只处理与数据库相关的操作:https://github.com/firebase/firebase-tools (2认同)
  • 不知道您是否已看到此内容,但可以针对Firebase服务器运行开发人员:https://firebase.googleblog.com/2015/04/end-to-end-testing-with-firebase-server_16.html (2认同)
  • 这正是我所做的,但问题是:如何在两个环境之间复制任何设置?例如.远程配置,观众设置等?手动将这些添加到生产环境非常容易出错. (2认同)
  • 我遇到的一个问题是对具有相同程序包和签名的多个Firebase实例进行身份验证。控制台不允许您将相同的软件包sha1添加到多个项目中,因此这可能是不可能的。文档说可以通过将clientid列入白名单来解决,但是我还没有成功。另一个解决方法是使用单独的程序包名称(更准确的说是“ applicationIds”),但是还有其他麻烦 (2认同)

ste*_*ing 11

正如每个人都指出的那样-您需要多个项目/数据库。

但是要回答有关是否需要将设置/数据等从开发复制到生产的问题。我有完全相同的需求。经过几个月的开发和测试,我不想手动复制数据。

我的结果是将数据备份到存储桶,然后从那里将其还原到另一个数据库。这是一种非常粗略的方法-我进行了整个数据库的备份/还原-但您也许可以朝着这个方向寻找一种更加受控的方法。我没有使用过-它是非常新的-但这可能是一个解决方案:NPM模块firestore-export-import

编辑:在这里Firestore备份/导出/导入信息Cloud Firestore导出和导入数据

如果您使用的是Firebase RTDB,而不是Firestore,则此文档可能会有所帮助: Firebase自动备份

您将需要正确设置权限,以允许您的生产数据库访问与开发相同的存储桶。祝好运。

  • 对于任何拥有几千个用户的项目,您最终都会将“一些”数据从生产数据库移动到登台或开发服务器。遗憾的是,这没有内置到 Firebase 中,但任何类型的项目都需要这样做。 (4认同)
  • 谢谢,这是迄今为止最好的答案。 (2认同)
  • 除了“正如每个人都指出的那样” https://firebase.google.com/docs/projects/dev-workflows/overview-environments 和下一个 Site Generell 最佳实践 (2认同)

bel*_*ood 10

我们选择在本地开发服务器上启动新的Firebase 模拟器实例进行测试和 UAT,将 GCP 完全排除在外。它是专门为这个用例而设计的。

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

  • 请谨慎假设模拟器是完全足够的测试环境。例如,对于需要设置复合索引的查询,模拟 Firestore 不会抛出任何错误,而真实的 Firestore(基于云)实例则会抛出任何错误。 (2认同)

Che*_*tan 9

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

按照这个

  1. 首先,在 Firebase 控制台创建一个新项目,将 id 命名为 YOURAPPNAME-DEV

  2. 单击“添加 android 应用程序”按钮并创建一个新应用程序。例如,将其命名为 com.yourapp.debug。新的 google-services.json 文件将自动下载

  3. 在您的项目 src 目录下创建名为“debug”的新目录并在此处复制新的 google-services.json 文件

  4. 在你的模块级 build.gradle 添加这个

    debug {
            applicationIdSuffix ".debug"
        }
    
    Run Code Online (Sandbox Code Playgroud)

现在,当您构建调试版本时,将使用“debug”文件夹中的 google-services.json,而当您以发布模式构建时,将考虑从模块根目录构建 google-services.json。


luk*_*kle 6

这篇博文描述了一种使用调试和发布版本类型的非常简单的方法.

简而言之:

  • 使用不同的应用程序ID后缀为每个构建类型在Firebase上创建一个新的应用程序.
  • 使用最新的JSON文件配置您的Android项目.
  • 使用applicationIdSuffix,根据构建类型更改Application ID以匹配Firebase上的不同Apps.

=>请参阅博客文章以获取详细说明.

如果你想使用不同的构建口味,阅读大量的博客帖子来自官方博客火力点.它包含许多有价值的信息.

希望有所帮助!

  • 请注意,这会在同一个项目中创建两个应用程序,因此您将分离一些服务(例如分析),但数据库将共享,因此不是真正的环境分离,如此处https://firebase.googleblog.com/2016/08/ Organizing-your-firebase-enabled-android-app-builds.html (2认同)

Kun*_*ire 5

我这样做的方式:

  1. 我在Firebase上有2个项目-一个用于DEV开发,另一个用于PROD
  2. 我的应用在本地也有2个分支-一个名为DEV,另一个名为PROD
  3. 在我的DEV分支中,我总是有DEV firebase项目的JSON文件,同样对于PROD

这样,我就不需要维护我的JSON。

  • 我确实理解,但根据最新的 firebase 版本,没有针对所提出的问题的通用解决方案。您必须尝试当前的选项并得出最佳实践。可能我的回答没有指出这一点,但我只是想帮助提问者表达我的观点。 (2认同)

web*_*ogs 5

我正在根据我刚刚找到的信息更新这个答案。

第1步

在 firebase.google.com 中,创建您的多个环境(即:dev、staging、prod)


mysite-dev

mysite-登台

mysite-prod


第2步

一种。直接移到您想要成为默认值的地方(即;dev)

湾 跑firebase deploy

C。部署后,运行firebase use --add

d. 将出现一个选项以从您当前拥有的不同项目中进行选择。

滚动到要添加的项目:mysite-staging,然后选择它。

e. 然后,系统会要求您输入该项目的别名。进入staging

再次为 prod 和 dev 运行项目 ae,这样每个环境都会有一个别名


了解您所处的环境

firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(其中一个环境的左侧会有一个星号。这就是您当前所在的环境。它也会以蓝色突出显示)


在环境之间切换

在它们之间奔跑firebase use stagingfirebase use prod移动。

一旦你进入你想要的环境,运行firebase deploy你的项目就会在那里部署。

这里有几个有用的链接...

命令行参考

部署到多个环境

希望这可以帮助。

  • 谢谢,我刚刚完整看完了视频。这就是说,我知道他针对不同的环境使用不同的_项目_,而不是同一项目_内的专用环境 (6认同)
  • 当您说多个环境时,您是指多个项目吗? (2认同)

Mic*_*sky 5

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

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/
Run Code Online (Sandbox Code Playgroud)

我对这个解决方案很满意,因为它不依赖于 build.gradle 技巧,我认为这些技巧太不透明,因此难以维护。例如,当我尝试使用applicationIdSuffix和 不同buildTypes的方法时,我发现当我尝试使用testBuildType. Android 似乎赋予debug buildType我无法检查以理解的特殊属性。

从道德上讲,根据我的经验,CI 脚本虽然非常透明且易于维护。事实上,我描述的方法有效:当我在模拟器上运行 CI 生成的每个 APK 时,Firebase 控制台的“运行您的应用程序以验证安装”步骤从

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

到:

恭喜,您已成功将 Firebase 添加到您的应用中!

对于所有三个应用程序,因为我在模拟器中一一启动它们。

  • 道格……你做了什么!:D 我不介意你在这里的回答,我相信这对一些正在寻求单独环境解决方案的人有帮助。 (2认同)