We’ve got Drupal development environments at the push of a button. We’ve got remote server setups with automated scripts, hourly and daily backups of everything we could need and a swanky dashboard to monitor it all. But still, the holy grail of the Drupal workflow eludes us. The holy grail, in this case being a completely code driven development process.

See, the problem with Drupal is that everything you change in the backend for your clients is stored in their database. That means when the site is live and running in the wild and users and content creators are doing their thing, any changes you make to the local development copy will need to be carefully replicated to the live site if you want to avoid any downtime. Not only is it time consuming, but it’s prone to developer error and there is no easy way to roll back changes if something doesn’t mesh with the live environment. Key changes made to sites can go undocumented in commit messages and can’t be compared or tracked.

Enter code driven development. Our work in progress plan here at Fuse Interactive is to start moving our configuration changes out of the database and into Features. Features are pseudo modules that allow for the exporting of a ton of configuration settings and variables, views and cck content types. On top of that, the ctools module furthers this by easily giving module maintainers a way to make their saved configuration data exportable.

From here, our next steps are:

• research the limitations of exportables in drupal and how we can leverage ctools in our own modules
• reading over the Kit specifications to see how we can best go about integrating Features into our current workflow
• get our own feature server up and running

We’ll keep you posted here on how everything goes and what we learn.