Two Environment.ts to rule them all.

Or Why most people still use Angular CLI in a wrong way.
Angular CLI (the swiss army knife for angular development) is a well known tool to Angular developer community. Most of front-end developers use it in daily tasks while creating and building Angular 2+ based applications, but are we using it the way it meant to be used?

When developing angular application there are two inevitable actions we take. One is running application do check and debug codebase we develop and another one is to pack it end deliver to the end user. While first one is easy thing to do and there is nothing too much to say, building, packaging and delivering production ready deployable angular application is a subject of constant discussions..

If you are working on a relatively small application, with couple of pages and fewer modules and there are no obligatory rules or release management process involved, you ca be as free as utilizing as many environment.ts as u wish and when time comes, simply provide environment as a build argument to the CLI and show off your new, shiny angular app, but what happens if you are working on a complex, enterprise web app with many modules and strictly controlled release life-cycle? What if your company has CI/CD process automated and once your PR is merged into master or release branch from there you loose all the control over it? This is the case many companies faced while doing SPA development. Problem became even more notable once vendors found out, that they not only have to build Angular based SPA through automated CI pipeline but also hand it over to their clients so they can deploy it in their internal infrastructure.

We all know that, in order for even CRUD based Angular application to function properly, there should be some API listening on a particular endpoint and this is where so called release saga starts. In most cases enterprise companies define many rules like versioning release schedule, deployment promotion through environments etc and as a result ruling them all is not as easy as it might look like.

Let’s take an example of a simple application which has the following CI/CD rules applied;

App versioning should be done using semver;
Any build should be done on some kind of the build server.
Releases must be kept in a repo and pushed on CD pipeline.
Every release should be first deployed on a QC environment.
Once QC passes it should be moved to the UA environment and tested by users.
If UA environment test passed release should be officially announced and app should be released.

In order to achieve this, immediate thought of most of the angular developers would be to create 3 separate environment config files and pas environment as a argument to the Angular CLI during build process so we explicitly tell CLI against which environment we are building and this might be completely valid approach but, let’s step back for a moment and take a look at the release pipeline we listed above. App versioning should be done using semver, this means once build server builds application and pushes it to the deployment pipeline, same version should go through all environments to its end destination (release to production). Now imagine that build system sets build number while kicking off release build. We are already facing blockers here and here is why.

What environment should build server make initial build against? You might answer QC, but do not forget release lifecycle dictates same build should be moved through environments and finally released and because build server changes build number on every build, passing application from one environment to another would result build system to rebuild providing different environment and increasing build number. As a result we would have releases in production like 18.2.1.3, 18.2.1.6, 18.2.1.9. You see we are already skipping 3 minor versions just to bring application to production release because of that rebuild every time we want to deploy it on the different environment.

Ok enough of problems we want solution!
There Should be some way to handle all this you might say and answer to that question is for sure big YES. So how we can handle such enterprise scale deployment and stay within regulations and process? Sure we will still be utilizing environment.*.ts files, but instead of creating per environment file, what if we create only two of them? What if we only had Environment.release.ts and environment.ts and as an example during development we used environment.ts while environment file our build server would ever use is environment.release.ts?

Main difference between those two files are the way things are defined inside. While in regular environment file you have values defined, inside release.ts file you would always use tokens instead of direct values and let deployment automation take care of substitution of those tokens with real values based on target deployment environment. As a result, entry in a regular environment.ts file like ApiEndpoint = ‘https://api.mydomain.com’ will become ApiEndpoint = ‘${ENDPOINT_TOKEN}’ (token example here is Octopus deployment style but most of the deployment automation software supports variable replacing during deployment) and what we are left now with is a very clean automation process where same version of the build can be deployed through all pipeline and release under the same version build agent created it initially.

Pros for the approach.
Endless extensibility - no need to create app itself if for example new environment is added to the pipeline.
Secure by default - because release build only contains tokens, any sensitive information can be kept in secret outside source control system and only provided during deployment time.
Easy to maintain - because token values are stored inside deployment system, usually they are managed at one place and can be easily changed by release management staff.without need for developer resources.