organising android + firebase project + cloud functions for dev staging production

Question

I need guidance on setting dev-staging-prod with firebase and android with full data isolation on the server side and ability to support the same via android. Plus I will have debug and release version of build. I am getting stuck because of the packagename + SHA constraint on firebase side. It is clear in firebase you can have the same SHA-1 in two projects, but the package names of the app (also called "application id") must be different. Likewise, you can have two projects that have the same package name, but they can not have any of the same SHA-1 added to them.

MUST HAVE: DATA ISOLATION OF ALL THREE ENVIRONMENTS I have a creatde 3 firebase projects under my account using Firebase console. 1) project-dev 2) project-staging 3) project-prod

I also want to in Android support 1) Debug 2) Release modes

I have a team of engineers who will push to dev, a select group pushing to staging and prod.

For dev isolation I can have developers use their sandbox account and hence the SHA key issue is resolved.

Staging/Prod: But how do I solve the staging/prod since the package name will be same. Do I have to add another suffix so that firestore won't complain? For debug and production I have rules to add applicationIdSuffix.

The package name will be com.mycompany.productname.

Release will be in prod. debug in dev and staging.

In Android I was planning on having flavours like this to point to the google_services.json so that the server side dimension of my app is handled. app/ src/ main/ dev/ google-services.json (for dev only) qa/ google-services.json (for qa only) prod/ google-services.json (for prod only)

and accordingly update the android app grade files

   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"
        }
    }

How do I manage the SHA keys now, since for an application id (package name) only one SHA key is permitted.

The combination of package name and SHA-1 must be unique

Answer 1

Here is a summary of the comments from Google's Doug and my original post.

Step 1) Firebase console: create three projects for different environments namely: dev | staging | production

Step 2) Dev work on their sandbox projects note for dev: Dev doesn't have to be like everything else. Each developer could have their own project under their own control in order to avoid clobbering each others' work Let each dev use their sandbox project (free account).

Step 3) Create a staging environment use debug builds without signing note for staging: Debug builds in dev and staging. No need for signing.

Step 4) Sign releases in prod note for production: share your dedicated signing keys with your trusted team members so they can deploy a manually signed app without having to unnecessarily define multiple apps per project. (remember You can have the same SHA-1 in two projects, but the package names of the app (also called "application id") must be different. Likewise, you can have two projects that have the same package name, but they can not have any of the same SHA-1 added to them. The combination of package name and SHA-1 must be unique)

Step 5) Integrate with Android SDK using product flavours Integration with firebase projects: Download the google-services.json file for these 3 projects and store them in the server dimension directories using the build.gradle file below (Module: app).

Step 6) Integrate with 3rd party using Blaze: Integration w/3rd party service: Upgrading firebase project to Blaze requirement. However if we need to use some 3rd party services etc, u need to have them add you as an owner of the project, then upgrade their projects to Blaze with your account's billing information. This way devs don't clobber each others data while unit testing their work.

Step 7) Verify your grade files Android gradle file for app:

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"
        }
    }

Step 8) Verify you android directories and google-service.json Directory structure in Android to accomodate the flavours: Drop google-services.json from firebase console into these directories.

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

Step 9) Upload cloud functions depending upon environment Now to manage my cloud functions, continue to use the different project environments, this way you avoid easy corruption of your production or staging data. The cloud functions will be deployed to staging and production.

For the dev environment, since all the developers will be creating their own project in sandbox mode, they will have to duplicate some configurations to make the project work correctly, e.g storage assets, cloud functions deployed that are needed etc. Individual control over projects requires individual deployments.

Step 10) Plan for the Future: Use CI/CD system for staging-prod. per doug: force all your deployments through a single CI/CD system that knows the credentials for those projects, and makes changes only after a successful build that passes tests. IMO, it's generally not acceptable for individuals from larger teams to each have access to special purpose projects.

ref: Continuous Delivery (CD) Continuous delivery is actually an extension of CI, in which the software delivery process is automated further to enable easily and confident deployments into production—at any time

Answer 2

It's probably easiest if you share your staging and release signing keys with only those people who should be able to deploy to those project environments. Even better, you could force all your deployments through a single CI/CD system that knows the credentials for those projects, and makes changes only after a successful build that passes tests. IMO, it's generally not acceptable for individuals from larger teams to each have access to special purpose projects.