Greg Dunlap, over at Palantir, has a post introducing a new “Deploy” module for Drupal. Most of the site design and behavior in Drupal is controlled through configuration stored in the database (as opposed to files on the file system). The ability to move configurations from one Drupal environment to another (like development to staging to production) has been an achilles heel for Drupal. You can’t just copy the database because then you would overwrite your production data with your test data. Assuming that you don’t want to be developing on the live site, you had to choose between manually repeating your work on production or resorting to some awkward SQL scripting hacks to move database stored configurations from one database to another. These scripts were always brittle because of Drupal’s reliance on an an ID field that is auto-incrememented – it is hard to keep those ID sequences synchronized across different databases. Deploy is a welcome improvement.
Deploy works by allowing an administrator to create a “deployment plan” and extending other modules to give an option to add their configuration to the deployment plan. When the administrator executes a deployment, Deploy grabs all the configurations and content that have been associated with the deployment plan plus their dependencies and pushes them to a target environment. Greg’s post has a nice screencast showing what it looks like to the user. Behind the scenes, Deploy adds a global unique identifier (GUID) field (in some companion tables) that is used to match up corresponding rows in the different environments.
It seems like Deploy falls short of addressing the common case where a deployment consists of a combination of configuration settings and content in the database and code in the file system. Deploy is for database-managed configuration only. For filesystem stuff, the handiest tool is a module called Drush that allows you manipulate a Drupal instance from the command line. This allows you to create a script (preferably in Ant or Make) to move files around and update a Drupal instance. Maybe it would be possible to configure Deploy to pull from another instance (rather than push). That way Deploy could be scripted in Drush for a comprehensive (database and file system) update.
These improvements are big steps in the right direction and reflect the impact of large companies running big and important Drupal sites. I expect this aspect of Drupal to be steadily improved and become standard practice by Drupal developers.
Related posts:
- Drupal Panels Tutorial Readers of the Drupal for Publishers know that Drupal lacks...
- CMS Architecture: Managing Presentation Templates Another geeky post… In my last post, I described the...
- CMS Architecture: Managing Content Type Configurations Warning: this post is highly technical. Non-programmers, please avert your...
- Code moves forward. Content moves backward. One of the primary functions of a web content management...
- Sacha Chua on Drupal Sacha Chua, whose blog keeps me hopeful that smart and creative...
Thanks for the writeup. Deploy is pretty much in its infancy now, I hope to continue growing it in the coming months. I do not right now have any plans to integrate with code deployment. I feel like the tools for managing that are pretty mature (talking mostly of svn and deployment scripts like Drush) and I’m more focused on solving other problems right now. However I hope to have a patch done soon to manage file attachments. I also know there are a lot of improvements being done to Drupal’s Version Control API module, so in the future linking the two together could be pretty easy.
High time! Been looking for this kind of thing in Drupal for 3-4 years. Together with the arrival of widespread unit testing and abandonment of PHP 4, Drupal 7+ should be significantly less crazy-making to manage.
Ironically, I think I’m finally enough fed up with the pains of coding custom behaviors in Drupal that I’ll be using rails/django/whatever for any future work. (I’ve said that more than a few Drupal projects ago, too…)
Isn’t this more ‘porting’ than ‘deployment’? I have been working on a static ‘deployment’ module for the ezpublish CMS. The name came from Plone who’se ancient extension ‘CMFDeployment’ did exactly that – cooked, then deployed, a dynamic (Python) CMS-based website to a bunch of static HTML files for offline viewing, high-burst traffic sites with no real need for user-dynamic interaction (our site at geonet.org.nz is an example)
This might be a bone of contention between different CMS installations (‘deployed’ or ‘ported’)
Just thought I might mention it
Russ
@Russ, it’s customary to use “publishing” for that, not “deploying”. I.e., static or dynamic publishing (baking vs. frying).
@Adriaan Bloem
Hmm, while have come across the terms baking/frying I can still see others becoming confusing as the word “publishing” is often used within the CMS itself to reset a content-item’s state e.g. from ‘draft’ to ‘published’ (eZPublish, Plone, perhaps others).
Unfortunately there is very little industry consensus on terminology. Words like “deploy” and “template” have different meanings in different platform communities. Bob Doyle, over at CMS Review, has been trying to put together a content management glossary but it never got off the ground. I think that we need to accept that words mean different things in different technologies and begin cross-community conversations with some level-setting and terminology definition.