One big flaw of the Angular CLI’s way of handling environments, according to the build once, deploy many DevOps principle, is that out-of-the-box Angular CLI wants you to create one separate build per environment.
Why should you only build once and reuse that build in all environments?
The reason why you don’t want to create a separate build for every environment is:
- It slows down CI pipelines because it needs to create a build for every environment
- It increases the risk of errors/differences in different environments because the builds are separate
- It adds unnecessary information about other environments in the code
- You might, for security reasons, don’t want to show confidential information in the environment config, which is saved to the version control
All these problems make me wonder why Angular CLI is opting for one build per environment. I sure wanted a solution to these problems.
How are these problems solved?
By making the deployment server substitute a config.json file, which is loaded on runtime by the app.
Making an Angular app use dynamic configurations
We want to make the Angular app only have two environment files:
Why two environments you may ask? One for local dev use, where you can put whatever you want when serving locally and one used when doing a prod build of the app. These environment files are getting most of its values from an
app-config.json file loaded on runtime as contrast to having all the environment info hardcoded in the environment files.
Create a new Angular CLI App
The first step is to create a new Angular CLI app by opening the terminal, go to the desired directory for the app and type:
ng new dynamic-config-demo
And this should create a new Angular CLI app for you.
Loading the config.json file on startup
All the environment configuration are gonna be stored in a
app-config.json file used by the
environment.ts file for referencing these values type-safely.
We simply create an empty JSON file inside the
assets folder called
The next step is to load the config.json file using an
app.init.ts initialization service:
This service will run on startup and will ensure that the app-configuration is getting fetched by using
fetch to get the configuration file and then save it in
window for making it globally available to the application. Note, when using
fetch you might need polyfills for IE browser support.
The app initializer service is set up in the
app.module like this:
Using an app initializer service creates a slight delay on the startup time of the application, but simple stuff like this won’t have a big impact on startup time. Still, I recommend that you let your users know to wait using a loading spinner.
Make the environment files use dynamic values
Now that we are loading the configuration JSON dynamically and saving them in
window, we want to be able to reference them type-safely. To do this, we should have three environment files:
environment is for using locally,
environment.prod is for production and
dynamic-environment is shared with
environment.prod for providing dynamic configuration.
dynamic-environment looks like this:
This is used in
environment like this:
Now we can try the new dynamic config capabilities out by displaying the environment name like this:
You can find a complete demo of an Angular app with dynamic configuration on my Github here.
Substituting the config.json file on the deployment server
Now that we have set the app up for dynamic configuration the next part is to set up substitution of the config file on the deployment server.
I have done this using Octopus, which has a smart function to substitute a JSON file with configuration values for the environment. Other deployment servers should have similar capabilities to substitute a JSON file right before deploying the app to the front end server.
We discussed the problems with the “Angular CLI” way of handling environment configuration with one build per environment and looked at why it is beneficial to do build once, deploy many instead. We looked at how to implement this using an app.init service which loaded a dynamic configuration file on initialization, with values set by the deployment server.
If you liked this post remember to comment, share and follow me on Twitter.
New posts every week. Subscribe so you don’t miss any.