You could use the Maven approach: for whatever the declarative configuration isn't powerful enough to specify, you write a plugin. That plugin can then be developed and managed just like any other software project, rather than having to bring those tools into the configuration realm.

Wait. In this case aren't the plugin itself "code in runtime config"?

edit: Now I understand that being a plugin it must have proper abstraction, but ad-hoc logic do exist.

I guess it depends on how you look at it, but if the plugin is a self-contained module that can be managed independently from the app it's configuring, I wouldn't really say it's code that's "in" the configuration.

> ... but ad-hoc logic do exist.

True. I don't disagree, no tool is right for every job.

Personally, I group these use cases under "infrastructure provisioning". The use case here is completely different - for example, you won't have a non-developer modifying the configs. So in this case, automation is a good idea.