为 dev staging 生产组织 android + firebase 项目 + 云功能

Question

我需要有关使用 firebase 和 android 设置 dev-staging-prod 的指导，并在服务器端实现完全数据隔离，并能够通过 android 支持相同的功能。另外，我将拥有构建的调试和发布版本。由于firebase端的包名+ SHA约束，我被卡住了。很明显，在 firebase 中，您可以在两个项目中拥有相同的 SHA-1，但应用程序的包名称（也称为“应用程序 ID”）必须不同。同样，您可以拥有两个具有相同包名称的项目，但不能向它们添加任何相同的 SHA-1。

必须具备： 所有三种环境的数据隔离 我使用 Firebase 控制台在我的帐户下创建了 3 个 firebase 项目。 1) 项目开发 2) 项目阶段 3) 项目产品

我也想在Android中支持 1) 调试 2) 发布模式

我有一个工程师团队，他们将推动开发，一个精选的团队推动登台和生产。

对于开发人员隔离，我可以让开发人员使用他们的沙盒帐户，从而解决 SHA 密钥问题。

Staging/Prod：但是我如何解决 staging/prod 问题，因为包名称是相同的。我是否必须添加另一个后缀才能使 Firestore 不会抱怨？对于调试和生产，我有添加 applicationIdSuffix 的规则。

包名将是 com.mycompany.productname。

发布将在生产中。在 dev 和 staging 中调试。

在 Android 中，我计划将这样的风格指向 google_services.json，以便处理我的应用程序的服务器端维度。 应用程序/ 源/ 主要的/ 开发/ google-services.json（仅适用于开发人员） 质量保证/ google-services.json（仅用于 QA） 产品/ google-services.json（仅用于产品）

并相应地更新安卓应用等级文件

   buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            applicationIdSuffix '.debug'
        }
    }
    // Specifies the flavor dimensions.
    flavorDimensions "server"
    productFlavors {
        dev {
            dimension "server"
        }
        staging {
            dimension "server"
        }
        prod {
            dimension "server"
        }
    }

我现在如何管理 SHA 密钥，因为对于应用程序 ID（包名称），只允许使用一个 SHA 密钥。

包名和SHA-1的组合必须是唯一的

Answer 1

这是来自 Google 的 Doug 和我的原始帖子的 cmets 的摘要。

第 1 步）Firebase 控制台：为不同环境创建三个项目，即：dev |分期|生产

第 2 步）开发他们的沙盒项目 dev 的注意事项：Dev 不必像其他所有东西一样。每个开发人员都可以将自己的项目置于自己的控制之下，以避免破坏彼此的工作 让每个开发人员使用他们的沙盒项目（免费帐户）。

第 3 步）使用调试版本创建暂存环境，无需签名 staging 注释：在 dev 和 staging 中调试构建。无需签名。

第 4 步）在 prod 中签署版本 生产注意事项：与您信任的团队成员共享您的专用签名密钥，这样他们就可以部署手动签名的应用程序，而不必为每个项目定义多个应用程序。 （请记住，您可以在两个项目中拥有相同的 SHA-1，但应用程序的包名称（也称为“应用程序 ID”）必须不同。同样，您可以有两个项目具有相同的包名称，但它们可以没有添加任何相同的 SHA-1。 包名和SHA-1的组合必须是唯一的）

第 5 步）使用产品风格与 Android SDK 集成 与 firebase 项目集成： 下载这 3 个项目的 google-services.json 文件，并使用下面的 build.gradle 文件（模块：app）将它们存储在服务器维度目录中。

第 6 步）使用 Blaze 与第 3 方集成： 与第 3 方服务集成：将 firebase 项目升级到 Blaze 要求。但是，如果我们需要使用一些 3rd 方服务等，您需要让他们将您添加为项目的所有者，然后使用您帐户的账单信息将他们的项目升级到 Blaze。这样，开发人员在对他们的工作进行单元测试时就不会破坏彼此的数据。

第 7 步）验证您的成绩文件 应用的 Android gradle 文件：

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            applicationIdSuffix '.debug'
        }
    }


  // Specifies the flavor dimensions.
    flavorDimensions "server"
    productFlavors {
        dev {
            dimension "server"
        }
        staging {
            dimension "server"
        }
        prod {
            dimension "server"
        }
    }

步骤 8) 验证您的 android 目录和 google-service.json Android 中的目录结构以适应不同风格：将 google-services.json 从 firebase 控制台拖放到这些目录中。

app/
        src/
            main/
            dev/
                google-services.json (for dev only)
            qa/
                google-services.json (for qa only)
            prod/
                google-services.json (for prod only)

步骤 9) 根据环境上传云函数 现在管理我的云功能，继续使用不同的项目环境，这样您就可以避免生产或暂存数据容易损坏。云功能将部署到登台和生产。

对于开发环境，由于所有开发人员都将在沙盒模式下创建自己的项目，因此他们必须复制一些配置以使项目正常工作，例如存储资产、部署所需的云功能等。单独控制多个项目需要单独部署。

步骤 10) 计划 未来：使用 CI/CD 系统进行 staging-prod。 per doug：强制所有部署通过单个 CI/CD 系统进行，该系统知道这些项目的凭据，并且仅在成功构建并通过测试后进行更改。 IMO，对于来自较大团队的个人来说，每个人都可以访问特殊目的项目通常是不可接受的。

ref：持续交付 (CD) 持续交付实际上是 CI 的扩展，其中软件交付过程进一步自动化，以便随时轻松、自信地部署到生产中

Answer 2

如果您只与应该能够部署到这些项目环境的人共享您的暂存和发布签名密钥，这可能是最简单的。更好的是，您可以强制通过一个 CI/CD 系统进行所有部署，该系统知道这些项目的凭据，并且只有在成功构建并通过测试后才进行更改。 IMO，对于来自较大团队的个人来说，每个人都可以访问特殊目的项目通常是不可接受的。