Drupal Configuration from Development to Production
Submitted by dave on Fri, 2007-10-05 19:09.
At the recent DrupalCon, a recurring topic of conversation centered around the challenges of developing sites on one or more development machines, then later integrating those changes to a production environment. I've had to deal with this for every one of my sites, and have come up with my own approach, which I've written about previously.
Recently, Michel Lévy-Provencal and several collaborators described their approach on drupal.org. It sounds very promising. The crux of it is to use odd database ids on their "integration server", while the production server uses even ids. So there are no conflicts when they make changes to the integration server, while their client makes additions/changes to the production server.
Further, they use mysql replication to get changes made on the production server back into the integration server. So they can at any point make a snapshot of the latest settings and content. A nice way to preserve a backup of an entire site.
I have some questions about their approach. Among them, how they handle database rows that have no numerical ids? And whether they replicate files uploaded to the production server?
My personal approach has some differences. What they call an "integration" server, I've been calling the "base" server. And where they use an even-odd scheme, I use ids less than 1000 in my base server, and greater than 1000 in all others. (This limits my base configuration to just 1000 nodes, terms, menu items, blocks, etc., but in my experience that has been enough.)
My base configuration feeds all my development instances, and the production instance. So, I make changes to my base server, dump the database using a special script, then check that dump into revision control. Then, on a development server or production server, I get the latest files from revision control, and run update.php. Using hook_form_alter tricks, I get update.php to import the database dump, this propogates settings from the base server into the instance running the update.
The bulk of my logic, for Drupal 5.x, is encapsulated in one module I call site_update, which I've recently checked into my sandbox. Its the only module I've written where all the useful code is in the .install file as opposed to the .module file. If you're interested in trying it, I'm happy to help you. Do start by reading my more detailed earlier article.
In the case of variables,
Submitted by dave on Mon, 2008-01-14 22:50.
In the case of variables, the variable name is the primary ID. If you configure a variable on any of your installations, that variable will not be overwritten by update.php, by default. However, if a new variable is introduced to your base database, update.php will write the variable to each of the installs. This works nicely when you add a new module to your base, configure it just right, then update.php on each instance will set the variables properly.
I also alter the update.php form, introducing some checkboxes that perform various actions. For instance I have a checkbox to reset theme related variables. So an update to the base settings can override existing settings, if the user explicitly checks the box.
It's true that Drupal databases are full of gotchas and most of what I'm talking about here is for advanced users looking to solve a difficult problem. It's not easily done.
drupal 6?
Submitted by shadzee on Sun, 2008-01-27 02:35.
Thanks for the article.
I'm new to Drupal, have done a couple of sites so far (version 5). One site in particular has the Gallery2 integrated in it, and now there is no way to continue developing using the local copy ;-( way too many things/settings were changed on the production site! mostly in the DB side of the Gallery2 ;-( even a DB dump does not work (again, I'm a new-bee here)
I'm a one-man operation, and I'm about a start a fairly large site for a none-profit organization. I've decided to start with Drupal 6, mainly for the ease of multi-language integration.
The question is, how would I integrate your solution for version 6 ? ;-)
Any hints would be appreciated.
no drupal 6 yet.
Submitted by dave on Mon, 2008-01-28 18:59.
I have not had time to port my work to Drupal 6. (I think you'll find that's true of quite a few third-party modules). I don't know how many changes will be required, but if you take it on, please let me know how it goes.
When I start working with Drupal 6 and have time to updated this stuff, I'll post a note on my website.
Auto-increment
Submitted by heyrocker@drupal.org on Tue, 2008-03-25 02:26.
Drupal 6 now uses auto-increment fields for IDs. Won't this be a huge road-block to all the special-id based solutions for node staging?
EDIT - Oh my bad, should still work based on the code I'm looking at. I had thought you were doing this through a hack to db_next_id()
I do it through a hack to
Submitted by dave on Tue, 2008-03-25 03:36.
I do it through a hack to autoincrement. ;)
Drupal's been using a mix of autoincrement and sequences table for a while now. My approach does require that I alter some tables to give them unique ids. I don't argue this approach is perfect, but it helps me do a lot that would otherwise be very difficult.
What! No comments???
Submitted by freixas@drupal.org on Mon, 2008-01-14 03:00.
Great article! Thanks for writing it and providing the code. I've been exploring my own alternatives, trying out migraine.py and waiting for autopilot. I'll check out what you've done—it sounds promising.
How do you handle things like the variables table? Giving it a primary ID won't save you from duplication.
Drupal databases are full of gotchas, mainly from the variety of authors implementing extensions. For example, the users table has a field called data which can contain any serialized data. If a module stores a Foreign Key in a this field, a hidden association is created. Trying to determine if this poses a problem when updating a production Drupal site can be interesting.
Anyway, thanks for your work and taking the time to write it up.
login or register to post comments