I agree, but the example posted is not consistent with what you said above or it is somewhat misleading. The example appears to demonstrate storage of sensitive configuration data in a JS module which is being required in the code. The best practice is to read configuration from environment variables directly, no?
I have no idea where you came up with this "best practice" from, it's one way to deal with it. The file is just fine as well as long as you don't store it in version control, i.e. add it to your .gitignore or similar.
If someone gets on the server they can read the process environment just as well as the file.
Being able to pass secret by environment variable is a MUST and part of the 12 factors. 12factor.net/config
You also need to commit your config file otherwise new people needs to understand how to works.
You could have a config.default but then it means you will have to maintain it and deal with optional configuration.
You quote the "12 factors" as if it is your holy book, that alone is something to worry about.
Also the only real point that page has is:
A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.
That doesn't mean or even hint at the need for environment variables, simply that your secrets and similar configuration isn't committed to your source in a human readable format. You CAN even commit your secrets and still pass that check, if you encrypt them so they can only be decrypted in the environment they're deployed to (often employed strategy e.g. when working with Salt Stack).
There is no reason secrets "must" be passed by environment variables. That might be a necessary strategy for the way you make your deployment, but not for everyone.
but then it means you will have to maintain it, like all of your code. I don't see what makes that a problem.
What I do often is commit a config that works for dev environment with a filename like config.example.*, and then simply deliver another config file for other deployments.
Additional concern is making sure your devs will have to spend minimal effort on fixing their environment, so it's even regularly worth symlinking or otherwise automating the use of your dev config in dev envs in a way that it doesn't accidentally get used on other environments if the config isn't properly created there.
One fun thing is when you specifically work with languages such as Python. If you have a file called settings.py which contains your settings coding against it is super easy from settings import PAYPAL_USER, and reconfiguring your app during unit testing is super convenient as you can just monkey patch the module.
This file can additionally of course have logic that reads environment variables into it, something like:
It is recognized as a bad practice because you're creating a file that is not requested anywhere and waiting to rot.
It falls as the same category as bad comments hinted by Robert C. Martin, Martin Fowler as well as others that have written on clean architecture and code.
Your devs will use their config.dev which is not committed so any time a new config need to be added or removed, there is no strong obligation to change the config.example file because everything will still work the way it is.
If you've ever work on projects with a big team either enterprise or open source. Many of projects using config.example simply doesn't work out of the box because of the config.example being just a piece of lies.
As for 12factors, well the 3rd point, says explicitly:
III. Config
Store config in the environment
I've mentioned the 12factors since the OP already mentioned it in another of his post.
Now without it being the holy grail or anything, it's a set of "best" practices that most if not nearly all recent IT books are derived from when they're talking about production ready code. Not having heard of it in 2018 is something to worry about.
@acostalima
was asking if env was a best practice and you cannot deny him that.
You surely could do another way, a best practice doesn't mean the "one and only".
As you say is depends on your way of deployment. For example, if you're running on cloud providers like AWS, then use of secret manager makes a lot of sense for any secrets config.
Your devs will use their config.dev which is not committed
Um no, don't do that. Use a config that IS committed as the developer environment config, so when you add something to it you automatically set the correct value for all other devs.
I agree, but the example posted is not consistent with what you said above or it is somewhat misleading. The example appears to demonstrate storage of sensitive configuration data in a JS module which is being required in the code. The best practice is to read configuration from environment variables directly, no?
I have no idea where you came up with this "best practice" from, it's one way to deal with it. The file is just fine as well as long as you don't store it in version control, i.e. add it to your
.gitignoreor similar.If someone gets on the server they can read the process environment just as well as the file.
Being able to pass secret by environment variable is a MUST and part of the 12 factors.
12factor.net/config
You also need to commit your config file otherwise new people needs to understand how to works.
You could have a config.default but then it means you will have to maintain it and deal with optional configuration.
You quote the "12 factors" as if it is your holy book, that alone is something to worry about.
Also the only real point that page has is:
That doesn't mean or even hint at the need for environment variables, simply that your secrets and similar configuration isn't committed to your source in a human readable format. You CAN even commit your secrets and still pass that check, if you encrypt them so they can only be decrypted in the environment they're deployed to (often employed strategy e.g. when working with Salt Stack).
There is no reason secrets "must" be passed by environment variables. That might be a necessary strategy for the way you make your deployment, but not for everyone.
but then it means you will have to maintain it, like all of your code. I don't see what makes that a problem.What I do often is commit a config that works for dev environment with a filename like
config.example.*, and then simply deliver another config file for other deployments.Additional concern is making sure your devs will have to spend minimal effort on fixing their environment, so it's even regularly worth symlinking or otherwise automating the use of your dev config in dev envs in a way that it doesn't accidentally get used on other environments if the config isn't properly created there.
One fun thing is when you specifically work with languages such as Python. If you have a file called
settings.pywhich contains your settings coding against it is super easyfrom settings import PAYPAL_USER, and reconfiguring your app during unit testing is super convenient as you can just monkey patch the module.This file can additionally of course have logic that reads environment variables into it, something like:
Regarding the config.example issue.
It is recognized as a bad practice because you're creating a file that is not requested anywhere and waiting to rot.
It falls as the same category as bad comments hinted by Robert C. Martin, Martin Fowler as well as others that have written on clean architecture and code.
Your devs will use their config.dev which is not committed so any time a new config need to be added or removed, there is no strong obligation to change the config.example file because everything will still work the way it is.
If you've ever work on projects with a big team either enterprise or open source. Many of projects using config.example simply doesn't work out of the box because of the config.example being just a piece of lies.
As for 12factors, well the 3rd point, says explicitly:
I've mentioned the 12factors since the OP already mentioned it in another of his post.
Now without it being the holy grail or anything, it's a set of "best" practices that most if not nearly all recent IT books are derived from when they're talking about production ready code. Not having heard of it in 2018 is something to worry about.
@acostalima was asking if env was a best practice and you cannot deny him that.
You surely could do another way, a best practice doesn't mean the "one and only".
As you say is depends on your way of deployment. For example, if you're running on cloud providers like AWS, then use of secret manager makes a lot of sense for any secrets config.
Um no, don't do that. Use a config that IS committed as the developer environment config, so when you add something to it you automatically set the correct value for all other devs.
Anyway, there is little point in continuing this.
Thanks you both for your insights. 🙂