Here is the problem with that. A dev pushes a change that requires a change to the env file. Another dev pulls down the code, but doesn't change the env file. Everything breaks. At really bad companies, DevOps sets env vars from somewhere other than that file passed around by devs - another failure point.

My proposal:

1. Key Vault | HashiCorp Vault | whatever is the source of truth for secrets.

2. When a developer adds a key, they add it to Key Vault and update code to use it.

3. On app startup, code checks the dev's local for 2 env vars ONLY, which allow access to key vault.

4. The app then tries to pull in all the env vars it needs by secret name.

5. If any are missing, it fails.

This keeps devs from having to pass around .env files outside of source control. Btw, Azure (and all other cloud) builds can be configured to pull env vars directly from Key Vault, so there's that benefit too.

There's an optional but very helpful sixth step: expose the loaded configuration (by pushing it to the logs, or as a /_config endpoint). For secrets, obviously don't expose the secret value itself, but do expose the vault address, secret identifier, and which version of the secret was loaded. This helps check that an application isn't using an outdated version of a secret.

"5. If any are missing, it fails."

That's literally all you need to solve the scenario you described with .env files.

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

You 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..

You can't keep secrets in code most of the time.

Usually 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.

Exactly, thank you for phrasing it much better than I did!

This is the workflow my company uses. It seems to work ok, but it’s hard to maintain discipline around using this pattern consistently

My company enforces this with two rules. One, deployment always builds and deploys exactly what's in the git repository, so there is no way to include anything else (secrets, configuration...) in a deployment. Two, it's obviously forbidden to commit secrets to the git repository (we enforce this through training and reviews, but it's fairly easy to add pre-commit hooks as well).