Decode your configuration

Recently, after various discussions around the net, I've realised something important. Repeat after me:

Configuration isn't code.

It might seem obvious written like that, but the current Drupal Configuration Management Initiative is based on the premise that configuration can be managed like code. Put in VCS like code. Pushed like code.

It's not "Configuration Management", it's "Configuration Enforcement", and it simply moves things from the "configured" category to the "coded" category. Granted, easily created and auto-generated "code", but code-like none the less. It's more like code than it's like configuration, including all the attributes that makes it hard to impossible for non-developers to work with.

What we, as Drupal developers, needs to realise that we're not king of the hill, as much as we want to be the rock stars. Needing a developer to commit the change to VCS, push the change to the server and trigger an update, in order to update the site email is going backwards. It should be a simple thing that a Site Builder or Administrator can do.

Administrator, Site Builder, Developer? Who exactly dictates configuration? Almost all the time I've been working on Drupal sites it has been highly customised sites, pretty much tailor made to the customers needs. What I've seen is the Developers dictating the configuration, by hand at first, through Features later. Because the Developer was in reality also the Site Builder. Not that most identified as such, Site Builders seems to be regarded as kind of second class citizens. If you can't code your own modules and feel comfortable pushing your configuration with VCS, you're just a step above the hobbyist.

But really, people like MerlinOfChaos has put considerable powers in the hands of the non-developer Site Builder. It's impressive what someone smart can put together only with configuration these days. It's a testament to the flexibility and power of Drupal and contrib modules. The Site Builder title is not to be scoffed at. If you identify yourself as a Drupal Developer, there's a high likelihood that you're a Site Builder too.

However, as Developers, we're still solving the Site Builder problems we have when we build sites, with developer tools. Tools that's inappropriate for the problem at hand. Configuration isn't code.

Why do we dictate configuration?

Reason one: it is necessary to provide what the customer asked for. If there is an image on articles, there need to be an image field on the article content type. It's part of the 'product' we're selling, we can't have random users removing the field, can we?

Reason two: We have code that relies on the configuration being a certain way in order to function. Code that needs certain fields, views, pages to exist in order to do smart things.

Reason three: It is our product. It is what we do. It's what we're paid for. We can't have random users messing with our work, devaluing the product, creating hard to track down by fiddling with obscure settings.

And the really weak reason: They shouldn't mess with configuration on production...

Which is really bogus...

What the customer asked for, might not be what the need tomorrow. If you build a house, and the owner promptly brick up one window, it's not the end of the world. It's always annoying seeing work being undone, but it's more important that the customer gets what they need.

As for reason two: You're doing it wrong. I know, I've done it myself plenty of times. We need to teach our Developer to develop for our Site Builder, not develop the whole feature implementation. If your code needs a specific field to work, the bare minimum implementation should check that the field exists and do nothing if not. The better implementation is, wait for it, configurable, and allows the site builder to configure what field to use. Not only does it ensure that code doesn't break the site when the configuration is incompatible, it also creates more reusable code. Uncouple your code from a specific configuration.

In regard to the third reason. Really, get over it. If someone wants to change things, why stop them? They bought it, if they mess it up, it's their option to do so.

As for the "they shouldn't change configuration in production", no, they shouldn't really, and that requires the ability to push configuration from staging. But that doesn't dictate that we should treat configuration as code, as seems to be the current rage. We can still lock down /admin on production, and we still have to manage configuration on staging, having multiple Developers and Site Builders messing about.

Let's give back Configuration to the Site Builders, and create a Configuration Management system that empowers them, regardless of whether they can code or use git. I've got a few ideas, but that's for another post.

Blog tags: