Modify configurations per environment without recompile

I would like to be able to send my Android, iOS or Uwp install package to my testers. They test it with config-values pointing to our test env. If they don't find any issues, the exact same binary (except for config values) should propagate to the store/production. In prod, of course the config-values needs to point to production servers etc.

I havent found any good solution for this. What I can find is Environment-aware config files (e.g. here). The problem is it needs a recompile.

I also found someone unzipping the Android APK, modifying the config file then resigning it again. That was an Android only solution, but perhaps something like that could be used for iOS and Uwp as well?

Isn't this something pretty meny of us would like to have? Does anyone know if it's in the roadmap for Xamarin to try and implement some kind of support for this? Or did I completly miss some existing solution to this problem?

Regards
Andreas

Best Answers

  • PaulNTUPaulNTU US ✭✭✭
    Accepted Answer

    Personally I would advise only one person on the team has control over issuing to the app store to prevent confusion and this should really be the developer/software manager

    However two other options spring to mind

    1) Is there a login procedure? If so you can create a admin account framework that redirects anyone to the test server if they have admin priviledges on their account

    2) An engineer type menu that allows you to set it to the debug server
    * A config file manually placed on the SD card by the tester that says "This is a test device". You app checks for the file in the public file space of the device, if it finds it then it points to your test server. If not then point to production server for all calls
    * A special sequence of taps (very obscure so that it cant be accidently activated) that's only known by your testers, this pops up a secret menu within your app allowing them to set your app to the test server

    I hope that gives you some useful pointers

  • JamesLaveryJamesLavery GB ✭✭✭✭✭
    Accepted Answer
    It's a hard one. You can do the same unpack/update/resign-pack for iOS but it's messy.

    What we do is have a central server API endpoint which returns the environment URLs for a given app version. This is called early on in the app startup - i.e. passing the app version and getting the URLs for the environment it should be using.

    Thus as an app progresses through environments (e.g. dev->test->UAT->pre-production->production) the server environment it uses can be changed without a recompile, by updating the data referenced by the central API.

Answers

  • PaulNTUPaulNTU USMember ✭✭✭
    Accepted Answer

    Personally I would advise only one person on the team has control over issuing to the app store to prevent confusion and this should really be the developer/software manager

    However two other options spring to mind

    1) Is there a login procedure? If so you can create a admin account framework that redirects anyone to the test server if they have admin priviledges on their account

    2) An engineer type menu that allows you to set it to the debug server
    * A config file manually placed on the SD card by the tester that says "This is a test device". You app checks for the file in the public file space of the device, if it finds it then it points to your test server. If not then point to production server for all calls
    * A special sequence of taps (very obscure so that it cant be accidently activated) that's only known by your testers, this pops up a secret menu within your app allowing them to set your app to the test server

    I hope that gives you some useful pointers

  • AndreasBrostenAndreasBrosten USMember ✭✭

    Ok, well… We do have a variant of the second step today (partly hidden env-selection).
    However, my goal was to be able to separate the config values in order to be able to update them without a complete recompile of the app. But as far as I can understand, there is no such "standard" solution.

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭
    Accepted Answer
    It's a hard one. You can do the same unpack/update/resign-pack for iOS but it's messy.

    What we do is have a central server API endpoint which returns the environment URLs for a given app version. This is called early on in the app startup - i.e. passing the app version and getting the URLs for the environment it should be using.

    Thus as an app progresses through environments (e.g. dev->test->UAT->pre-production->production) the server environment it uses can be changed without a recompile, by updating the data referenced by the central API.
  • AndreasBrostenAndreasBrosten USMember ✭✭

    @JamesLavery thanks for your answer. A question regarding it. By just using the version of the app, how do you determine what Environment to use? I'd like to use the same packaged app e.g. v 5.3.0 in dev, test, qa, prod (or whatever). So how do my central server endpoint know what ser of Environment url:s to return?

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭

    Wouldn't a version only be in one environment at a time due to its progression through the dev/test/release process? We always increment the version as we release - so V1.0.0 is released, then the next version to go to test and onwards is V1.0.1 at least.

    To allow better granularity you can use the build number (version number in Android, build in iOS), which needs to be incremented on each store release, in conjunction with the Version.

    Note that another wrinkle is that we do allow an override, controlled by compiler variables, so that we can point a dev build to other environments (one might want to test a bug fix against test/qa/live). We also have a big red banner on the app UI when this is set, so that hopefully developers/testers will realise they're not running against the normal environment - so that we don't release with this set!

  • AndreasBrostenAndreasBrosten USMember ✭✭

    Ahh, I see. The central API is the one in Control of how long in the chain a specific version has passed.
    An override seems resonable.

    Thanks for your input! I'll take it in consideration when we decide upon our solution.

Sign In or Register to comment.