Deployment And Change Management - What Helps Now

Error message

  • Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /usr/www/users/gdd/heyrocker/includes/common.inc).
  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /usr/www/users/gdd/heyrocker/includes/menu.inc).

Having defined the problem in my last post, we can now look at some of the options currently available for dealing with it. None of them is a complete answer, but they can all help out with some of the pieces. As a reminder, I'm just concerned with the problem of deploying changes to live sites for the moment. This is not a complete list by any means, but it is some stuff that I've found useful. Have you got another tactic you use to manage these types of changes? Let me know in the comments. If you're interested in this topic you should also subscribe to the Build Systems & Change Management group on groups.drupal.org.

  • Content Copy - If you're using CCK you're probably already familiar with Content Copy, an included module which creates a scripted CCK Content Type (and its associated fields) which you can then copy and paste into another site to be imported. It works really well, barring a couple bugs here and there (it likes to add an extra line to nodereference fields which you have to remove by hand.) One can also take these exports and use drupal_execute() to install them with a script like so:
    include_once ('./'. drupal_get_path('module', 'node' ) . '/content_types.inc');
    include_once ('./'. drupal_get_path('module', 'content') . '/content_admin.inc');
    $export = file_get_contents('your_file.txt');
    $values = array('type_name' => '', 'macro' => $export, 'op' => 'Submit');
    drupal_execute('content_copy_import_form', $values);

    So you can actually write a PHP script to do an import of your CCK content types, push it to your production server, and run it to get your new content types in place. This is pretty cool, although it takes a little work in advance to set up. I've found it's easiest to put the export scripts from content copy into a separate file and read them in, because there are various issues with needing to escape quotes or $strings that cause irritance when putting them inline. More on this here.

  • Views Export - Views offers the ability to export and import view definitions the same way content copy does. The definitions can also be dropped into code as described by Adrian in his comment to my last post, however I believe this removes the ability to maintain your view through the UI which may or may not meet your needs. I'm not a fan of this because we have a lot of less technical staff who still know enough to do things through the admin like create content types and views, but don't necessarily want to be diving into the code to make changes.
  • Journal - Journal adds a text box to every form on a Drupal site for users to enter comments on their changes. These comments are then saved to a custom log. On any form using system_settings_form (most forms under /admin), this field is required. This can be really useful while developing for keeping notes on your changes so you don't forget about things later when you're trying to put together a deployment plan later.

And here are a some things that are more experimental or not-quite-there but good from a "food for thought" perspective.

  • Autopilot - I wasn't even going to bring this up, since I really only wanted to talk about technology that actually exists. However Workhabit just got a Drupalcon proposal in under the wire, in which they claim we will finally be seeing a new release of Autopilot. Ever since their first announcement, Autopilot has looked like it is the product which will solve everyone's problems in this realm. Unfortunately, in the 9 months since that announcement, there's been little to see other than an alpha version they have disavowed, and a series of posts on their blog claiming the new release is just around the corner. Honestly it has been a little frustrating. I seriously hope the product is ready soon. If it is even half as great as their initial posting made it sound it will render many of these discussions moot. EDIT: It is now over 5 months since I posted this, and there is still no sign of AutoPilot. At this point I find it difficult to consider it anything but vaporware.
  • CoCKtail - This is pretty new, and the code is experimental, but it looks interesting. CoCKtail is a UML-like language for describing CCK types developed by Raincity Studios. It aims to address all sorts of configuration and deployment issues related to CCK content types, and while I'm not sure I buy into it, its very interesting and I look forward to see where it goes. You're best going to their website for all the details, there are a series of blog posts where they lay out everything the want to do with CoCKtail (Part 1, Part 2, Part 3) as well as the comments on those posts. Raincity has also proposed a session on CoCKtail at Drupalcon.
  • MySQL Dump Hacks - In theory it would be easy in a lot of cases to just mysqldump the appropriate tables, strip out the rows you want, and import these rows into the other database. Unfortunately this runs up against a huge obstacle - there's no way to guarantee your primary keys will be unique between the two databases. I read a posting somewhere a while ago, possibly on the change management group although if so I can't find it now, that posed a novel workaround for this - he hacked db_next_id() on his dev server such that it only produced odd IDs, and on his production server such that it only produced even IDs. Thus he could move records around from one to the other without risk of collision. I had actually toyed with a similar idea at one point - setting up my dev environment with two database connections (dev and live), and hacking db_next_id() to always pull IDs from live using db_set_active(). All your keys are then generated from one source. Please note, I am not actually advocating doing either of these things, they're just interesting ideas.

Next up, ideas! Progress! Maybe even some proof-of-concept code if I'm not too scared.

I wrote two chapters of this book - Drupal 7 Module Development and I co-wrote it with Matt Butcher, Larry Garfield, Matt Farina, Ken Rickard, and John Wilkins. Go buy a copy!
I am the owner of the configuration management initiative for Drupal 8. You can follow this work at the dashboard on groups.drupal.org.

I used to work at NodeOne in Stockholm, Sweden. NodeOne is the largest pure Drupal consultancy in Europe. They have built websites for clients like IKEA, SFBio, and Möbler. If you need some work done get in touch!