React-native-firebase: [Question] How i can use a test and production environment?

[approached]

Hi @ all,

How i can use a test and production environment?

I have one codebase which is managed with git.
I use follow modules: firestore, authentication, analytics, crashlytics and storage. Firestore and storage is most important.

Has anybody a idea?

[mikehardy]

I think there is some commentary about this in older issues if you search, we should probably put a FAQ or guide up

There are a couple ways to do it but they all start with the same idea: you have multiple firebase projects in the cloud, one for each environment you want to support.

Then for Android I think the best thing is to use build flavors, and maintain the google json file in for example android/app/src/environment name/google-services.json - one for each environment. So I have:

mike@isabela:~/work/Kullki/ksocialscore/packages/public-app (rebranding *) % find . | grep google-services.json
./android/app/src/qa/google-services.json
./android/app/src/staging/google-services.json
./android/app/src/prod/google-services.json
./android/app/src/dev/google-services.json

I use product flavors (google up the Android docs for them) - which are a separate axis from "release" vs "debug" so that each environment get's a unique application Id and I can have all of the environments installed on the same device at the same time.

So my android/app/build.gradle has this chunk in it:

    flavorDimensions "release_streams"
    productFlavors {
        dev {
            applicationIdSuffix ".dev"
            versionNameSuffix applicationIdSuffix
        }
        qa {
            applicationIdSuffix ".test"
            versionNameSuffix applicationIdSuffix
        }
        staging {
            applicationIdSuffix ".staging"
            versionNameSuffix applicationIdSuffix
        }
        prod {

        }
    }

For iOS I use Targets in Xcode as the build separation (they work like flavors in Android's gradle build system - make one per backend Firebase project/environment), and I made a sub-directory for each GoogleService-Info.plist. Then for each environment Target in Xcode I select the correct plist file and select that it should be a member of the target

So I have

mike@isabela:~/work/Kullki/ksocialscore/packages/public-app (rebranding *) % find . |grep GoogleService-Info.plist
./ios/KScoreApp/Prod/GoogleService-Info.plist
./ios/KScoreApp/Dev/GoogleService-Info.plist
./ios/KScoreApp/Staging/GoogleService-Info.plist
./ios/KScoreApp/Test/GoogleService-Info.plist

And each of those targets gets a separate bundleId (prod is 'com.kompai.kscore', dev is 'com.kompai.kscore.dev' etc for me) for the same reason as the android flavors above - I can have each environment installed on the same device at the same time. I do have to manage each as a separate product in Apple Developer Connection which is a pain in the butt, but that is mostly one time setup, then they all TestFlight happily.

To make them easy to tell apart I have different icons for the non-prod environments, and I do a bit of work in the app to tell (based on bundleId or applicationId) what flavor is executing so I can enable or disable different features but nothing too fancy.

That's it. All the files are in source control, the firebase descriptor files don't get copied around (that's another way to do it but I don't like "clobber this file with this other file..." as a build step) and I have 4 fully separate apps so they aren't fighting each other for your devices and emulators.

A fair bit of initial infrastructure to build but it's worked great for almost 2 years after getting it going. Hope this helps.

[andersonaddo]

This sounds like solid advice, this should definitely be added to or linked to in the docs

[mikehardy]

I unfortunately no longer really have perspective on it nor remember all the steps :rofl: - but if you try it and keep track of the steps then propose a docs PR about one person every couple of days (my guess based on support traffic) would probably read it and praise your name...

[andersonaddo]

I think I'll do just that.
If I run into problems I'll dm you on discord.

EDIT: There already seems to be a pretty solid guide right here actually.

[approached]

@mikehardy thank you so much. Your post help me a lot. Your solution works great but i'am a single developer so i have other easy solution.

Android:
I use just debug (dev) and release (prod). This blog post help me:
https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html

File structure:

./android/app/src/debug/google-services.json
./android/app/src/release/google-services.json

./android/app/build.gradle

buildTypes {
  debug {
    signingConfig signingConfigs.debug
    applicationIdSuffix ".debug" // <- added
  }

For IOS i will try tomorrow

[Salakar]

As @approached suggested, on Android the Google Services plugin does support reading from specific build 'type' directory by default, e.g. you can place the json file in a android/app/src/{build_type} folder if you are using multiple build types.

Source: https://developers.google.com/android/guides/google-services-plugin#troubleshooting

[mikehardy]

@approached that does seem like it would work, but realize that you won't be properly testing prior to prod, in that release builds typically go through minimizing and obfuscation, which can lead to a whole class of bugs on both platforms. If you don't have a test environment where you test release type builds you may endure some surprises along the way. I think that's a low risk - possible worth it in your situation - but something to keep in mind.

[stale[bot]]

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.