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?
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?