Using a different Application Id for debug/QA (via gradle Build Flavor) and Google App Engine
Creos via StackOverflow
I'm thinking of changing the name of my application id by appending "-DEBUG" which allows me to install both a release and a debug version of it on the same device (and also helps with stuff like Crashlytics filtering though there are other ways to deal with that) but it poses a problem with the google app engine backend since all the security features are tied to the application name as they should be.
I'm thinking of two possible solutions but wanted to see if anyone else has hit this issue and may have a more elegant approach.
1) instead, I can change the app version via gradle versionNameSuffix though this doesn't allow the two version of the app to co-exist
2) register both app ids with the app engine backend
Am I thinking about this the wrong way? In general, how do people deal with Release vs QA instances of their apps and setting up corresponding versions of their backends? Also, do the Release vs QA backend instances share the same data store? Thanks.
Please DO NOT REPLY directly to this email but go to StackOverflow:
http://stackoverflow.com/questions/28388488/using-a-different-application-id-for-debug-qa-via-gradle-build-flavor-and-goog
Alex Martelli via StackOverflow
Personally I've always used the suffix approach you're considering, except with a more systematic set of suffixes (-dev if there's a single "in development" version, -dev-<developersusername> if each developer in the team gets a separate one, -staging, -qa, -canary, -prod and the like, depending on the exact deployment workflow for a given app).
And, any external system I need to use from the various versions, such as an app engine backend in your case, I register all relevant versions on. Typically a small, simple script makes light work of that!-)
I would consider it very risky to share a datastore or other persistent bunch of data between a production version (whose data are presumably precious and absolutely to be preserved) and in-development versions that are quite possibly buggy -- couldn't one of the somewhat-expected bugs in the new versions wipe out precious to-be-preserved production data?
Please DO NOT REPLY directly to this email but go to StackOverflow: