1

As per angular documentation, I understand that the production keys can be places in the "environment.prod.ts". However, what is not very clear to me is when during the build stage are:

  1. Does the variables being included in the final build? If yes, wouldn't this make the env variables exposed to the public which were supposed to be a secret?

  2. If the variables included in the build, what is the correct way to deploy a production version of the application? (Let's say the app will be hosted on firebase)

Thank you :)

Duy Anh
  • 750
  • 1
  • 7
  • 24
  • 1
    In addition to the nice answer Reza gave, here is a similar question with a very good write up on this subject. https://stackoverflow.com/questions/51489904/angular-6-should-i-put-secret-environment-variables-in-environment-ts-file – canpan14 Mar 04 '20 at 15:00

1 Answers1

1

For First question: If you have something critical you have to add it in your backend not frontend, for example most of secret keys should be there.

For seconds question: Usually I do this

In environment.prod.ts instead of real values I put place holders, for example

{
   api_url: '#!api_url!#'
}

So it will be build by this values, and in the time of deployment, I replace these place holders with actual values, in the main*.js file.

If you have automated the deployment, there are some tasks in Azure Devops and Octapus for that, for sure Jenkins should have something too.

By doing this also you will be able to deploy the same package to different environment, because replacing token with values happens before each deployment

The other reason to have place holders is you don't keep them in source control, and for example no body in dev team will have access to prod configs, and it goes in the hands of devops engineers

Reza
  • 18,865
  • 13
  • 88
  • 163
  • What's the advantage of using placeholders like that? – Cerbrus Mar 04 '20 at 15:02
  • @Cerbrus you can deploy same package to different enviroments, for example same package goes to `QA` then if it's signed off same goes to `UAT` and then `Prod`. Since replacing the values happens on each deployment, not in the build – Reza Mar 04 '20 at 15:04
  • Isn't the whole point of `environment..ts` to have separate build configurations that you use for separate environments, so you _don't_ have to do "manual" (automated) replacements? – Cerbrus Mar 04 '20 at 15:05
  • @Cerbrus yes that is another way, the cons of that is you keep values in source control, and also build time will be increased because you need to build multiple times for multiple enviromnet – Reza Mar 04 '20 at 15:07
  • That last paragraph makes more sense, but then I'd consider having a separate config file... – Cerbrus Mar 04 '20 at 15:13