Greenscreen hazmat suit

I’m currently building TWO Drupal 8 sites from the ground up, and migrating a third, so I’m getting really comfy with drush config-export/import . (I loves me some drush config!)

I’ve been thinking about [config in DB] for a while now & why it bugs me. I’m not a strong developer so I admit my opinion is ignorant. So consider this rant (it will be long…) from the product owner perspective.

I’m sure there are good architecture reasons to store config in the DB, but I can’t think of many good business ones. (There are other reasons to choose Drupal but they are related to Drupal’s community & contrib ecosystem. And — not a light consideration — the existence of soup-to-nuts hosting environments like Pantheon.)

The short version is, anything I do on prod should be ephemeral. If I’m making an architecture change I’m doing something dangerous. A system that encourages me to do this by design has suspect business value.

The long version is, if Im managing a business unit with a website in it, do I want a tool powerful enough that I, a plain old Marketing Person, might brick my site using the admin GUI? What is the business case for that? So of course I’ll hire a dev…or retain a shop!

OK so maybe I have a dev or two on staff, or a shop on retainer, and they’ll use the GUI tools for me. (or aha, drush…hold that thought…) Unless I have legacy reasons for that team to choose Drupal, why would they? What does the fact of drush’s existence say about developers’ respect for the admin GUI tools, which are ostensibly there so I can make their my architecture changes…and which I am so afraid of making IRL, that I had to hire these bozos?

if the team is making changes ON PROD (e.g. layout, content types, views) that need to be communicated to other devs, I’d prefer a) not to be making those changes ON PROD in the first place and b) using agnostic dev tools (text editors, diff, source control, make, etc.) to make them.

The example I’d use here is creating a new content type, which is a BFD in Django. You have to edit models.py, generate migration script(s), migrate the data, and reboot the webserver. (Sidenote, I keep most of my django business logic as methods on data models because I hate writing views (ie. select/filter queries) so much.) So it always alarms me to see clients creating content types willynilly on their Drupal sites. If I didn’t have routine backups running, we could lose a whole class of data! Not just the DATA, mind you, but the CLASS of data, and all of its entity relationships!

This is the Django Dude in me for sure but that is dangerous as hell; it should not even be POSSIBLE using an admin GUI. You should have to put on a hazmat suit and fire up a greenscreen and run make scripts to make it happen.

(There is a similar but less fraught parallel here with nondestructive architecture changes, esp Views. Views aren’t any easier for me to write just bc I have a pointyclicky interface for it. Couldn’t I just don the hazmat suit & edit a config file to achieve the same thing?)

And in the real world, even for small scale changes e.g. a new panel layout, the client (or internal stakeholder team) will want to see that change on a non-prod server first anyway. In which case you have to find a way to share that change up to prod. Which leads us (finally!) to drush config. i.e. a greenscreen tool, which I was trying to avoid with the admin GUI anyway right?

So, long story short: I’d rather use the dev tools and not a bolt-on.