How to manage multiple environments from single project

If you are developing a mobile app or and API like we did with the Griffin App, there is a high likelihood you need to deploy these to different environments. You might have a production environment, development environment, or even more.

Coordinating the migration and deployment of these across mobile, local APIs, cloud APIs, and cloud databases can be challenging! You don't want to split your codebase into multiple projects because maintenance because a nightmare. So how do you manage the release environments for API or Mobile app from a single project?

Read more about how Axway built the Griffin App and API and provided a solution for assisting with the safe return to the office at Axway

APIs

For our projects, we use AMPLIFY API Builder to create APIs that we can deploy anywhere. The project can easily be built and tested locally and then deployed to an docker environment (AMPLIFY Runtime Services, in our case). The challenge is we needed to be able to deploy the same codebase to multiple environments. In order for this to work, we needed to design it with this in mind. With the API projects, there is not too much that has to be changed.

Put all API keys, API endpoints, etc. in an environment file (i.e. .env.prod)

API_BUILDER_APIKEY=123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

Anywhere in your API you need to then reference these variables like this:

const apikey = process.env.API_BUILDER_APIKEY;

With API Builder, you can modify the default.js file to replace the hard-coded API key with a reference to the value from the environment file.

Change the package name in package.json based on your environment.

For Production environment, you might have:

{
    "name": "acme-api-production"
}

whereas your Development environment might have:

{
    "name": "acme-api-development"
}

Ideally, you would write a short npm script that would do the following when you switch environments:

package.json

{
    "scripts": {
        "switch":   "node ./scripts/switch-environment.js"
        "switch:dev": "npm run switch dev"
        "switch:prod": "npm run switch prod"
    }
}

and inside switch-environment.js, you would do the following:

• Change name in package.json file
• copy environment file (i.e. .env.prod -> .env)

Cloud Databases

Axway's MBaaS solution supports a production and development environment, out of the box, so in many ways this part is much easier. You simply need to take the keys for each environment and put them in the environment files we created above.

There is no built-in way to migrate data between environments but Leor Brenman has created a great script that can be used to move data. You can read all about it in his post about the Axway MBS Custom Object Data Migration Utility.

Mobile Apps

Changing environments within your AMPLIFY Titanium mobile app can be a bit more complex but it is the same general concept. There are several things that will need to be updated when changing environments:

• App icon (optional)
• tiapp.xml
  • id
  • name
  • guid
  • description (optional)
  • publisher (optional)
  • oauth info (endpoints/clientid/etc)
  • api info (urls/keys/etc)
• branding (optional)

I usually chose to change the App Icon so users can distinguish between the dev/prod apps that might be installed side-by-side on their device.

Like your API project, you will then have some npm scripts you can run to switch environments:

package.json

{
    "scripts": {
        "switch":   "node ./scripts/switch-environment.js"
        "switch:dev": "npm run switch dev"
        "switch:prod": "npm run switch prod"
    }
}

Because we are not reading from environment files for mobile projects, you will need to store your environment specific urls/api keys/etc in a json file which your script can then read and make the appropriate changes to your tiapp.xml file before building your project.

If you are going to completely white-label your mobile apps, there are other things you will need to change such as branding and colors but not all of that is necessary for a simple environment change.

Wrapping it up

Using and expanding upon these techniques can allow you to enable the flexibility you need to fit the unique requirements of your organization! There are also many other ways that teams can support multiple environments. Let us know in the comment section below how you and your team tackle these issues!

We have open-sourced the source code for our Griffin App and APIs! Using Axway AMPLIFY Platform to create solutions for real-world challenges!

Ask-a-Geek questions are answered by Brenton House, an API and Mobile geek who has been doing dev work for 25+ years.