Passing adal configuration dynamically to Azure DevOps release pipelines

Question

I have a .net core SPA application that I integrated with Azure AD using the ADAL library. I have the ADAL configuration (Client ID, tenant ID etc.) within the app.module.ts file and they are currently pointing to the local development environment values.

I am using Azure DevOps to build and deploy the application. I have an Azure build pipeline to build and publish the artifact at the end of the CI cycle and I have a release pipeline to take the artifact and deploy it to a QA environment (windows VM) using the IIS Web Deploy Task.

The release pipeline successfully deploys the application to the VM but it still uses the old development values for ADAL configuration and hence the authentication doesn’t work on the QA server.

I know I could use the environment.ts file(s) to pass the ADAL configuration dynamically based on the environment that I am deploying to but the problem is the publish artifact task of the build pipeline by default uses the ‘--prod’ parameter to build the artifact (.zip) that I am using to deploy to QA which means it is going to always use the environment.prod.ts file irrespective of the environment that I am deploying to.

My idea is to build the artifact once at the end of the CI phase and deploy the same artifact to any higher environments. How do I achieve that with .net Core + Angular 7 + MSAdalAngular6 + Azure DevOps?

Thanks!

Answer 1

What you're describing is having a different configuration per environment. It tends to be less error prone to have each environment's configuration checked in and at runtime have the app determine where it's running and which config to load.

You could do this by setting a specific environment variable through the Azure portal or some other mechanism.

Answer 2

How I always pass configuration is the build once idea you state. Use a standard configuration file which is tokenized, then in Azure DevOps you can use a task like 'replace tokens' in the release pipeline, which will use the pipelines variables (you may need to un-archive then re-archive when replacing tokens).

My team usually has both a default config with local entries for development and a tokenized one for deployment (which gets renamed during release), this also allows you to keep secrets out of source control. e.g. appconfig.json and releaseconfig.json

The other common approach is to store all configuration as environment variables on the server, which comes with its own problems, and retrieve them on application startup.