
Environment Variables and Why You Shouldn't Use Them - gkop
https://support.cloud.engineyard.com/hc/en-us/articles/205407508-Environment-Variables-and-Why-You-Shouldn-t-Use-Them
======
stephenr
So this is apparently from earlier in the year, but doesn't seem to have been
discussed here before?

I'll come out and say it: I disagree with this completely, and the "solution"
suggested (a config file) is honestly worse (and has a lot more risks).

My work for clients is a mix of web app development and ops/infrastructure -
the single best improvement that I ask client dev's to do (regardless of what
I'm doing for them) is to start using Env Vars for environment specific stuff.

Sometimes it takes a while for developers who are used to projects with a
single config file, committed to the repo, and thus using the same db
credentials for all environments, local dev, shared dev, staging, prod - but
ultimately it makes things _so_ much easier.

In particular I thought it was quite odd to complain about Env Vars being a
"hack" to get around limitations, immediately before explaining that a popular
(I guess?) app server for ruby/rails has some caveats when reloading env vars.

> However, this method (Env vars) is just a hack to get around their file
> system limitations and can cause unexpected problems.

> When using environment variables with Unicorn, hot restarts don't pick up
> changes to environment variables.

Pot, kettle, black, etc.

> All gems used and sub-processes launched have access to all variable values,
> so if any of them log or transmit the output of 'export' or ‘env’, your
> private data can be exposed.

If the sub-process/code doesn't need access to the environment variables,
reset the environment the process starts in.

If the sub-process/code does need access to the environment variables,
shouldn't you be actually reviewing what it does and how it works?

