3 ms·
The difference is any time the .env config is updated, all engineers have to update their .env file. So with .env file: - developer adds to .env - pushes cod
by meowtimemania 3y ago
The difference is any time the .env config is updated, all engineers have to update their .env file.
So with .env file:
- developer adds to .env
- pushes code
- all developers see failures in dev env due to missing env var
- all developers search slack/email to figure out what went wrong
- all developers update their .env file and things are working again
————-
In gp’s comment
———-
- one person works on feature that introduces new config
- failure happens in their local environment
- they update config backend and push code
- all other developers get updates with no changes needed
- throw1234651234 3y agoExactly, thank you for phrasing it much better than I did!
- Rapzid 3y agoYou can also just supply defaults that can be locally overriden.. Benefit is they are reviewable in the same PR that adds the code depending on them..
- throw1234651234 3y agoYou can't keep secrets in code most of the time.
- Rapzid 3y agoUsually not big secrets. I do and have done both and a blend. Secrets for external services needed in dev usually in parameter store. Kinda depends on the existing work flow. There is so much to do you should be tackling problems that move the needle and chip away at small stuff, pet peeve stuff in smaller time-boxed increments. It depends, always it depends.