Tokenizing Angular Environment Configuration in Azure DevOps | josh-ops

[utterances-bot]

Tokenizing Angular Environment Configuration in Azure DevOps | josh-ops

Using the ‘build once deploy many’ concepts with an Angular application and Azure Pipelines

https://josh-ops.com/posts/angular-tokenization/

[arevarn]

Hi, great post! How come you are not using Releases in DevOps for your Deployment job? It looks like all the steps are being run in the build pipeline, right?

[joshjohanning]

@arevarn great question! We are using 'Multi-Stage' YAML Pipelines which allow us to combine our build + release pipelines into one pipeline. The main benefit is that we can define our Release pipelines as YML as well, but in addition, everything is combined in one pipeline for a singular, concise view.

Each "environment" is separated by stages. Example:

• build
• deploy to dev
• deploy to N-env
• deploy to prod

I usually set up the build stage with a single job (to build/test the app). I typically then will set up my Deployment stages with a single job as well, however, we want to use a deployment job here. The deployment job let's us specify an Environment (for approvals).

It will look like this:

stages:
- stage: deployDev
  displayName: deploy to dev
  jobs:
  - deployment: dev 
    pool:
      vmImage: 'ubuntu-latest'
    environment: myapp-dev
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo "hello world"

Hope this helps!

[jonlighthill]

@joshjohanning great article. If you have a pwa app and are using the angular service worker, changing any file contents will mess up the ngsw.json hashes and would have to regenerate the hashes.

[daleclements]

Encountered a problem with approaches like this. Since the replacement is done AFTER the main..js is built, changes to configuration won't cause main..js to be built with a different hash because it has the same exact content at build time. Users can then get the out-of-date cached main.js because it has the same name.

[joshjohanning]

Encountered a problem with approaches like this. Since the replacement is done AFTER the main..js is built, changes to configuration won't cause main..js to be built with a different hash because it has the same exact content at build time. Users can then get the out-of-date cached main.js because it has the same name.

@daleclements

Ahh- interesting. So you're saying if you are just changing a configuration setting and nothing else, the hash will be the same and the cache won't pick up the new config value?

I wonder if there is some way to force it to get a new hash?

Perhaps cache busting? From https://stackoverflow.com/questions/55402751/angular-app-has-to-clear-cache-after-new-deployment

[tarifrr]

@joshjohanning - I tried cache busting, the old values get served

[joshjohanning]

@tarifrr Bummer.

Did you ever end up figuring out how to do this by chance?

[tarifrr]

@joshjohanning - Nope, we had to ditch the tool and do the builds separately. As mentioned by others, the hash codes remain the same and caches can't detect any changes in the config values. Hence, they don't pull the latest build artifacts from the origin servers.

[rcmazo]

I get the tokenized configuration but I don't get how the file replacement is a better option. With the file replacement update. You replace the environment.ts with the environment.prod.ts file during build but that would require your build command to be ng build --configuration=production for that to work. If you have 3 environments (dev, test, prod) you will run the build command with the corresponding environment? Hope you could elaborate more on the file replacement way.