4 ms·

And what about "configs" like Kubernetes deployments?

• shawnz 7y ago
  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.
  • rfoo 7y ago
    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.
    • shawnz 7y ago
      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.
• jevgeni 7y ago
  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.