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:

1. It slows down CI pipelines because it needs to create a build for every environment
2. It increases the risk of errors/differences in different environments because the builds are separate
3. It adds unnecessary information about other environments in the code
4. 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: environment.ts and environment.prod.ts.

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 app-config.json.

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, environment.prod, and dynamic-environment.

environment is for using locally, environment.prod is for production and dynamic-environment is shared with environment and 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.

Conclusion

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.