We are developing an angular 5 application that must run in different environments (dev, qa, int, uat, prod), and connect to different APIs depending on the environment. We have traditionally have only 4 environments and we have a environment file for each with environment variables.
But now with the introduction of the 5th environment - integration (int) - Instead of adding a different release channel in Octopus Deploy with a different build (that use environment variables), they want the app to handle the configuration by detecting the domain in the url (at run time) and select configuration in a switch/case structure. e.g:
let apiUrl = 'https://api.example.com/v2';
const location = window.location.origin;
switch(location){
case 'https:dev.hostname.domain':
apiUrl = 'https://dev-api.example.com/v2';
break;
case 'https:qa.hostname.domain':
apiUrl = 'https://qa-api.example.com/v2';
break;
case 'https:int.hostname.domain':
apiUrl = 'https://int-api.example.com/v2';
break;
case 'https:uat.hostname.domain':
apiUrl = 'https://uat-api.example.com/v2';
break;
}
This is because some people are resisting to modify the CI tool configuration to add the new release channel. But this doesn't feel right to me, I think the environment variables is a better solution (different environment file is used depending on the target in the compilation phase). e.g:
//QA environment file example
export const environment: Environment = {
production: 'false',
apiUrl = 'https://qa-api.example.com/v2',
otherEnvVar: 'whatever',
}
And then importing the environment where needed:
//Some app file
import {environment} from '../environments/environment';
// ... my code ...
But when trying to explain the reason I can not think of anything other than this solution seems 'ugly' to me (which is not a valid reason). So now I'm wondering if is there a valid reason to have environment variables separated from the application logic.
What would be the superior solution and why? or both are equally valid?