This doesn't work for everyones infrastructure setups, but it's worked well for mine.

That works fine if there's a limited number of environments, but it becomes a pain if you're running the same app in too many, or if someone else needs to deploy it independently of the developers.

No it doesn't. It's trivial to generate the full set of configs using a script, if you have too many to manage manually.

or if someone else needs to deploy it independently of the developers

And how exactly do envvars help with that? The set of envvars still needs to get pushed with each deployment. envvars are just a special config file.

> requires strict separation of config from code. Config varies substantially across deploys, code does not.

What's the difference between config and code? Config is that which changes between deployments / environments.

Basically, you'd have a git repo for code, and a separate git repo for environment scripts. I've seen organizations use a whole separate infrastructure for config, but that always seemed like overkill to me.

It's definitely more convenient to use the same repo, especially in the declarative containerized world; you can make sweeping changes or roll them back in a single atomic commit.

That said, if open source is the intent, certainly use multiple repos from the beginning so you avoid git gardening when releasing later.

Set at build time. They come from a build config file/script as part of the build. They're not perfect, but just about every tool ever made has a way of understanding environment variables - the same can't be said for any given config file.

Here's a real world example: I want one source of truth for my build configuration, but my build itself pulls together libraries and binaries in a number of different languages and build systems. How would you handle that with anything but environment variables and a master shell script?

But the script is in VC surely?

> How would you handle that with anything but environment variables and a master shell script?

Again, where is that master shell script? What args do you give it?

My preference is that you have one environment variable, and your config is keyed off that.

If that environment variable is not supplied, fail noisily.

You can take it one step further and define a single ConfigMap resource per environment, containing all of the required variables across your application, and then have all the various containers reference it ‘blindly’ when they are deployed. Said configuration resource would exist in version control but deploy independently from the functional codebase(s).

The idea is that the application environment / infrastructure should own the config data, not the application code itself. 12 factor practices require that devs draw a boundary between app and infrastructure.