New configuration managemen module

In my last post about configuration management I mentioned I have a few ideas on an alternative way of dealing with configuration. As CIM, my attempt implement those ideas has gone into alpha, it's about time I elaborate a bit on it.

CIM is for Drupal 8, and uses the new configuration management of the Configuration Management Initiative for it's low-level interfacing to the configuration. CIM is short for "Configuration Interchange and Management", the name reflecting that it really does two jobs.

The management part is useful, even if you only have one Drupal instance, as it keeps a history of configuration snapshots, allowing you to track the changes, and revert/rollback to known good configurations. With Features, as it's currently used, this part of the picture is rather lacking in usability, with the configuration history hidden in git history, mixed in with more or less related code changes, possibly even spread over multiple repositories.

Configuration interchange is between Drupal installations. You peer up your development site with the production site (or staging site, if you prefer), and pull down a copy of the production configuration. After the usual fiddling about, you can then push your configuration changes from the development site to the production site (or, again, staging).

This is what already works in alpha1. Two things that still needs to be implemented is 'pull configuration, but reapply my local changes' (like git rebase) and some sort of interactive merge tool, for when conflicts appear. Both should be straightforward to implement.

One thing that this system doesn't handle yet, is the issue of needing a configuration change, together with a code change. While I was advocating in my last post that code depending on configuration is to avoided, I also know that in the real world it happens, and needs to be dealt with.

The way I suggest dealing with this, is by allowing development sites to create a delayed push. The changeset is checked by the receiving site as usual, and if it applies, it is put in a queue for later. From thereon, all changeset pushed is only accepted if the they don't cause the changesets in the queue to fail applying. The delayed changeset is also associated with some identifier, which a developer can provide to a function in an update hook, to apply the delayed changeset to the configuration. Alternatively, delayed changesets can be applied by hand in the backend, if you're rolling things out by hand anyway.

This not only allows developers to push configuration upstream, it's also simple enough to let non-developers implement and test configuration changes on a staging site before pushing them live.

Blog tags: