How to handle multiple environments for a mobile app?

Question

Consider an enterprise mobile app available for both Android and iOS, with build and release pipelines.

What I'm trying to achieve is a promotional model for the release pipeline, such that the app binaries are built only one time in a build pipeline, and are then promoted through the environments to production by a release pipeline:

1. Build pipeline builds the IPA and APK files
2. Release pipeline is triggered after a successful build, and deploys to the Test environment
3. QA manager promotes to the QA environment, and it's pushed out to testers
4. QA manager promotes to the Production environment, and it's pushed out to end users

[ APK/IPA ]---->Test ---> QA ---> Production---->[ Same APK/IPA ]

There are corresponding Test, QA and Production versions of a backend API that the app must connect to (e.g. while the app is at the Test stage, it should connect to the Test API) - but how can the app know which one to connect to?

Now, if I was creating a web app, this is simple enough to handle using environment variables, so the web app knows which environment it's running in - not so with a mobile app.

The only way I can figure to handle this is for the app to connect to a kind of configuration API, sending it's version number, so it's "told" what environment it belongs to by the backend. But this seems a little inflexible.

Is there perhaps some way to bundle a file in the APK/IPA files to let it know which environment it belongs to? What ways are there to handle this?

Sonyasoo

using fastlane and jenkins we can build APK/IPA with different environments. For this app must contains different schema that configured with corresponding Endpoints. – Bacteriophage

Setting up Environment for iOS is here – Bacteriophage

@lal-krishna not sure if I'm missing something, but that looks like you're building new binaries for each environment, with a different config file for each build? That's exactly what I'm trying to avoid; the aim is a single build that gets promoted through the environments – Sonyasoo

@Sonyasoo what approach did you end up taking? – Economical

@Economical I stuck with building new binaries for each environment, then later it was moved it to the "configuration API" idea, such that there was a lookup table of version numbers that decided what configuration each calling version of the app should receive. It's complex and inflexible though, so doubt I'd go there again - I'd still love some way of bundling a config file with a built binary. – Sonyasoo

@Sonyasoo I'm looking for exactly the same as you, I've been researching a lot but haven't found anything yet. I don't think this is something (easily) feasible for mobile apps, anyway I'm not a mobile expert, so any input would be very appreciated. – Vittoria

@gabriel-c nothing new since my last comment here: options are configuration API (I don't like it), or just accept different builds for each environment - realistically, as long as you build from the same commit, the risk from this is extremely low; by beef is idealistic as much as anything – Sonyasoo

Answer 1

I've done this before. I don't have time to go too in depth right now. The general idea is slightly different. We block the app from usage until registration through the back end api. We use the serial number to target the device, so each device gets their own env as part of registration. Then we use persistence on both ends to keep track of the device env based on the serial number or unique identifier

Clarisclarisa