[nickpsecurity]

The linked part about config makes sense. It's a specific instance of a general concept that shows up in hardware and software engineering. That's that things that reusable things that don't change should be separated from those that change often.

In this case, we have code and [configuration] data. The data can and will vary considerably while reusing the same code. They should be separate so data changes don't require recompilation. Further, any change of code can change its behavior. Better to have code that's already vetted via review and testing to handle specific types of input data. That way you can keep changing the data without re-assessing the code. There's also a minor benefit in efficiency when you can re-use binaries already created and integration tested while just generating new configuration data. Those minor things can add up if you're constrained in CPU/memory.

[hamax]

> data can and will vary considerably while reusing the same code.

This is the complete opposite of my experience. We deploy new code to production 10 times per day and change configuration a couple of times per month.

What do you keep in configuration that changes this often?

[nickpsecurity]

Well, it depends on internal projects vs external ones. Internal ones might work as you described. External ones will have many more deployments than code changes for a given module.

[hamax]

Agreed. I always worked with internal project so it didn't cross my mind.

[mafro]

I agree with everything you say! Notice I'm not saying that the 12 Factor App is incorrect or bad - I think it's quite the opposite. It just concerns me that people treat it as gospel, and quote it like it's some holy work that cannot be disagreed with.