Drupal deployment/testing/don't-how-to-call it tool

Question

Setup is following: Drupal project, one svn repo with trunk/qa/production-ready branches, vhosts for every branch, post-commit hook that copies files from repository to docroots.

Problem is following: Drupal website often relies not only on source code but on DB data too (node types, their settings, etc.).

I'm looking for solution to make this changes versionable. But not like 'diffing' all data in database, instead something like fixtures in unit tests.

Fixture-like scripts with SQL data and files for content that should be versionable and be applied after main post-commit hook.

Is there anything written for that purpose, or maybe it would be easy to adapt some kind of build tool (like Apache Ant) or unit testing framework. And it would be very great, if this tool know about drupal, so in scripts I can do things like variable_set(), drupal_execute().

Any ideas? Or should I start coding right now instead of asking this? :)

Answer 1

It sounds like you've already got some infrastructure there that you've written.

So I'd start coding! There's not anything that I'm aware of thats especially good for this at the moment. And if there is, I imagine that it would take some effort to get it going with your existing infrastructure. So starting coding seems the way to go.

My approach to this is to use sql patch files (files containing the sql statements to upgrade the db schema/data) with a version number at the start of the filename. The database then contains a table with config info in (you may already have this) that includes info on which version the database is at.

You can then take a number of approaches to automatically apply the patch. One would be a script that you call from the postcommit that checks the version the database is at, and then checks to see if the latest version you have a patch for is newer than the version the db is at, and applies it/them (in order) if so.

The db patch should always finish by updating aforementioned the version number in the config table.

This approach can be extended to include the ability to set up a new database based on a full dump file and then applying any necessary patches to it to upgrade it as well.

Answer 2

My approach to this is to use sql patch files (files containing the sql statements to upgrade the db schema/data) with a version number at the start of the filename.

I was thinking of file (xml or something) with needed DB structure, and tool that applies necessary changes.

And yes, after more research I agreee: it will be easier to code it than to adapt some other solutions. Though some routines from simpletest drupal module will be helpful, I think.

Answer 3

You might want to check out the book Refactoring Databases.

The advice I heard from one of the authors is to have a script that will upgrade the database from version to version rather than building up from scratch each time.

Answer 4

Previously: Drupal Source Control Strategy?

Answer 5

Did a presentation on this at a recent conference (slideshare link) -- I would STRONGLY suggest that you use a site-specific custom module whose .install file contains versioned 'update' functions that do the heavy lifting for database schema changes and settings/configuration changes.

It's definitely superior to keeping .sql files around, because Drupal will keep track of which ones have run and gives you a batch-processing mechanism for anything thaht requires long-running bulk operations on lots of data.