change management

A couple days after I posted my last article, I went to del.icio.us to see if anyone had bookmarked it. A user named timbaileylondon had, with this note - "We need to get on top of this. The last one in particular made me cringe." Too true on both counts.

A few weeks ago I was trying to chase down a bug in content copy, because it was causing us problems with some content types we were trying to move. I had never dealt with FAPI much before, and it was a real eye-opener discovering I could script content type exports and imports easily in a few lines of code, and then further realizing I could actually script any form the same way. I started thinking about how many Drupal objects can be scripted quickly this way - node load/save, user load/save, any form, etc. It was then that I started thinking that maybe all we need to tackle the deployment problem is a) a way to abstract each of these pieces of data and b) a way to move them from server to server. Maybe Drupal doesn't need an overarching deployment solution, it just needs some glue.

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?

I had been hoping to get together with people at Drupalcon this year to discuss issues surrounding deployment and change management. Unfortunately I will not be able to go. So this will have to act as my contribution to that discussion, which will hopefully carry on well beyond Boston. There are three parts - The Problem, Things That Help Now, and Some Ideas For The Future.