ConfigCentral is an experiment in building a centralized configuration service, based on recommendations provided in Jez Humble & Dave Farley's book, Continuous Delivery (pp 44-46).
So far I'm thinking I'll start out with a RESTful API, and some kind of NoSQL database. I'm not sure whether a document-centric DB or a key-value store will fit this best, so that's an area of exploration. It could even end up using git as a database, which would get us versioning for free.
Humble & Farley recommend a model consisting of a set of tuples for each configuration property, depending on three things:
- The application
- The version of the application
- The environment it runs in (i.e., dev, staging, uat, production, etc)
They also provide the following use cases to consider when modeling configuration info:
- You'd need to be able to specify a new set of values for applications deployed into this new environment.
- This might introduce new configuration settings and get rid of some old ones.
- Ensure that when deploying this new version to production, it can get its new settings, but if you have to roll back to an older version it will use the old ones.
- Ensure that any new settings are available in the new environment, and that the appropriate values are set for this new environment.
- You should be able to update, very simply, every configuration setting that references this database to make it point to the new one. This seems to suggest a resource model for some config values, rather than all being dumb strings (although that sounds like a good starting point)
- You should be able to use your virtualization management tool to create a new instance of a particular environment that has all the VMs configured correctly.
- You may want to include this info as part of the configuration settings for the particular version of the application deployed into that environment.