独立开发和开发Firebase环境

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

如果你正在使用firebase-tools，有一个命令firebase use可以让你设置你正在为firebase deploy使用哪个项目

firebase use --add会显示你的项目列表，选择一个，它会问你一个别名。从那里你可以firebase use alias和firebase deploy将推送到该项目。

在我个人使用中，我在Firebase控制台中有my-app和my-app-dev两个项目。

这篇描述了一个调试和发布构建类型的非常简单的方法。

简而言之:

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

=>参见博客文章的详细描述。

如果你想使用不同的构建风格，请阅读来自firebase官方博客的广泛博客。它包含很多有价值的信息。

希望有帮助!

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

遵循这个

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

2. 单击“Add android app”按钮并创建一个新的app。例如将其命名为com.yourapp.debug。新的谷歌服务。Json文件将 自动下载

3. 在你的项目src目录下创建名为“debug”的新目录并复制新的google-services。Json文件

4. 在你的模块级别构建。Gradle添加这个

   debug {
   applicationIdSuffix ".debug"
   }
   

Now when you build a debug build google-services.json from "debug" folder will be used and when you will build in release mode google-services.json from module root directory will be considered.

我的做法是:

1. 我在firebase上有2个项目-一个用于DEV，另一个用于PROD
2. 在本地，我的应用程序也有两个分支——一个叫DEV，另一个叫PROD
3. 在我的DEV分支，我总是有DEV firebase项目的JSON文件&PROD也是如此

这样我就不需要维护我的json了。

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

Firebase有一个页面，介绍了如何为dev和prod设置它

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

为您的项目设置环境配置存储环境 数据中，可以使用firebase的功能:config:set命令 重火力点CLI。可以使用句点对每个键进行命名空间分组 相关配置一起。记住，只有小写字母 键中接受字符;

.

. 例如，要存储“某些服务”的客户端ID和API密钥， 你可以输入:

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

检索当前环境配置 存储在项目的环境配置中，您可以使用firebase 功能:配置:。它将输出类似这样的JSON:

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

正如每个人都指出的那样，你需要不止一个项目/数据库。

但是为了回答你关于需要能够将设置/数据等从开发复制到生产的问题。我也有同样的需求。在几个月的开发和测试中，我不想手动复制数据。

我的结果是将数据备份到一个存储桶，然后从那里将其恢复到另一个数据库。这是一种相当粗糙的方法——我做了整个数据库备份/恢复——但是您可以从这个方向寻找一种更可控的方法。我还没有使用它-它是非常新的-但这可能是一个解决方案:NPM模块的导出-导入

编辑:这里的Firestore备份/导出/导入信息

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

步骤1

在firebase.google.com中，创建多个环境(即;Dev, staging, prod)

mysite-dev

mysite-staging

mysite-prod

步骤2

a.移动到你想作为默认值的直接位置(即;dev)

b.执行firebase deploy命令

c.部署完成后，执行firebase use --add

d.会出现一个选项，让你从当前拥有的不同项目中进行选择。

滚动到要添加的项目:mysite-staging，并选择它。

e.然后您将被要求为该项目提供一个别名。输入暂存。

再次为prod和dev运行a-e项，这样每个环境都将有一个别名

了解你所处的环境

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(其中一个环境的左边会有一个星号。这就是你现在的处境。它也将以蓝色突出显示)

在环境之间切换

运行firebase use staging或firebase use prod在它们之间移动。

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

这里有一些有用的链接…

CLI Reference . sh CLI Reference

部署到多个环境

希望这能有所帮助。

为了解决这个问题，我创建了三个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和不同的__abc1方法时，我发现当我试图使用testBuildType切换构建类型时，我无法运行测试，甚至无法编译。Android似乎给了debug buildType特殊的属性，我无法检查理解。

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

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

:

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

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

并根据:https://firebase.google.com/docs/android/setup或Crashlytics: https://firebase.google.com/docs/crashlytics/get-started?platform=android设置SDK

首先，放置各自的google_services。json为每个buildType在以下位置:

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

注:根app/google_services。这个文件应该根据构建变量在根json文件中复制json代码

现在，让我们在你的:app的构建中创建一些gradle任务。Gradle自动移动适当的google_services。Json到app/google_services.json

复制到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或:assemblerrelease运行之前的某个时间运行上述适当的复制任务。让我们看看当:assemblerrelease运行时会发生什么:在/gradlew文件中复制这个

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

复制到app/Gradle文件中

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

现在，无论何时:app:processReleaseGoogleServices被调用，我们新定义的:app:switchToRelease都会被预先调用。同样的逻辑用于调试buildType。您可以运行:app: assemblerrelease和发布版本google_services。Json会自动复制到你的应用模块的根文件夹。

我们选择在本地开发服务器上为Test和UAT启动新的重火力点模拟器实例，而将GCP完全排除在外。它正是为这个用例设计的。

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