I manage Operations at Chingu, Inc. We help bridge the knowledge you have gained via your learning activities and the experience employers seek through global remote team projects. Come join us.
Location
St. Louis
Education
Southeast Missouri State University, Webster University
I've taken a look at your article and your approach has merit. I'm still gathering my thoughts on this, but as of this moment I still prefer an approach (independent from any particular .env package) of documenting the names of the environment variables in the project readme.md, but still excluding the .env file from the project.
However, something I need to explore is setting up .env files unique to each environment. In dotenv this can be done by customizing the path in the call to the config function. For example .env.production, .env.staging, .env.development, etc.
Having said this though, there may be an opportunity to simplify this by creating a wrapper package to do this outside of application code.
This is a good topic for discussion and I'm interested in any additional comments and suggestions you might have.
For me, that one works prefectly fine. Like I can commit my .env files, colleagues can override it using .env.local, set environment specific variables like .env.staging.
Initially, as you said I updated everything in the readme and added .env to .gitignore. However, I tell everyone that there is a new variable in the readme. Most of the time front-end devs come to us and says "this thing doesn't start!". Me "pls update env file, run migration and try again. If not I'll come"
But if you add .env from .gitignore and add everything in readme, then what's the point of it? Someone who got access to your git repo just need that readme right?
I manage Operations at Chingu, Inc. We help bridge the knowledge you have gained via your learning activities and the experience employers seek through global remote team projects. Come join us.
Location
St. Louis
Education
Southeast Missouri State University, Webster University
I don't add the environment variable values to the readme. Only the names, a description, and a sample value (not the real value).
I understand the downsides, and I'm revisiting my use of environment variables because there are downsides as you've pointed out. Using an encrypted vault for secrets like I'm currently doing still means new devs need help setting things up.
I manage Operations at Chingu, Inc. We help bridge the knowledge you have gained via your learning activities and the experience employers seek through global remote team projects. Come join us.
Location
St. Louis
Education
Southeast Missouri State University, Webster University
I use 1Password, which is a commercially available password keeper, to store information, not just about my personal accounts but also to keep information about the projects I participate in.
There are quite a few different products that do this. The important thing is to pick one that's encrypted, easy to use, and works well on your OS.
Some teams I've worked on use a vault like this with shared credentials.
I manage Operations at Chingu, Inc. We help bridge the knowledge you have gained via your learning activities and the experience employers seek through global remote team projects. Come join us.
Location
St. Louis
Education
Southeast Missouri State University, Webster University
I've taken a look at your article and your approach has merit. I'm still gathering my thoughts on this, but as of this moment I still prefer an approach (independent from any particular
.envpackage) of documenting the names of the environment variables in the projectreadme.md, but still excluding the.envfile from the project.However, something I need to explore is setting up
.envfiles unique to each environment. Indotenvthis can be done by customizing the path in the call to theconfigfunction. For example.env.production,.env.staging,.env.development, etc.Having said this though, there may be an opportunity to simplify this by creating a wrapper package to do this outside of application code.
This is a good topic for discussion and I'm interested in any additional comments and suggestions you might have.
For me, that one works prefectly fine. Like I can commit my
.envfiles, colleagues can override it using.env.local, set environment specific variables like.env.staging.Initially, as you said I updated everything in the readme and added
.envto.gitignore. However, I tell everyone that there is a new variable in the readme. Most of the time front-end devs come to us and says "this thing doesn't start!". Me "pls update env file, run migration and try again. If not I'll come"But if you add
.envfrom.gitignoreand add everything in readme, then what's the point of it? Someone who got access to your git repo just need that readme right?I don't add the environment variable values to the
readme. Only the names, a description, and a sample value (not the real value).I understand the downsides, and I'm revisiting my use of environment variables because there are downsides as you've pointed out. Using an encrypted vault for secrets like I'm currently doing still means new devs need help setting things up.
ok got it. Could pls explain bit more about "vault of secrets", how does it work? where do you store it?
I use 1Password, which is a commercially available password keeper, to store information, not just about my personal accounts but also to keep information about the projects I participate in.
There are quite a few different products that do this. The important thing is to pick one that's encrypted, easy to use, and works well on your OS.
Some teams I've worked on use a vault like this with shared credentials.
Nice! Thanks for the info
Anytime! This has been a great discussion and its making me rethink what I'd previously taken for granted. Thank you!