How to Manage Multiple Environments From a Single Project
Coordinating the migration and deployment of a mobile app or API across mobile, local APIs, cloud APIs, and cloud databases can be challenging...
Join the DZone community and get the full member experience.
Join For FreeWe recently created an Axway Mobile App for all employees that, in addition to helping our remote teams stay connected, is helping us plan a safe and responsible return to the office where possible. Our Griffin Innovation Lab in partnership with the CTIO office came together, and in two weeks, put together a full backend infrastructure to record office utilization.
The major feature going into the Griffin App was to be an Office Scheduling assistant. We are a global organization with 2,000-plus employees and 29 offices in 17 countries, so to return to the office — in each of our countries and locations — our teams had to follow different requirements.
If you are developing a mobile app or an API like we did with the Griffin App, there is a high likelihood you need to deploy these to different environments.
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 code base into multiple projects, as maintenance can become a nightmare.
APIs
For our projects, we use the AMPLIFY™ API Builder to create APIs that we can deploy anywhere. The project can easily be built and tested locally and then deployed to a docker environment (AMPLIFY Runtime Services, in our case).
The challenge is we needed to be able to deploy the same code base 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
)
xxxxxxxxxx
API_BUILDER_APIKEY=123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

Anywhere in your API, you need to reference these variables like this:
xxxxxxxxxx
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:
xxxxxxxxxx
{
"name": "acme-api-production"
}
whereas your Development
environment might have:
xxxxxxxxxx
{
"name": "acme-api-development"
}

Ideally, you would write a short npm script that would do the following when you switch environments:
package.json
xxxxxxxxxx
{
"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:
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
For mobile, it gets 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
xxxxxxxxxx
{
"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.
Finally, we are excited to announce that we are open-sourcing the code for the Axway Griffin App and API! You can read more about the Griffin App here or jump right to the Griffin App GitHub repo to take a look at the code!
Let us know in the comment section below how you and your team tackle these issues!
Published at DZone with permission of Brenton House, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments