A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2008 yearDrupal deployment/testing/don't-how-to-call it tool - page 1
User InfoPosts
Drupal deployment/testing/don't-how-to-call it tool#1
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? :)

posted date: 2008-12-18 03:58:00


Re: Drupal deployment/testing/don't-how-to-call it tool#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2008-12-18 03:58:01


Re: Drupal deployment/testing/don't-how-to-call it tool#3
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.

posted date: 2008-12-18 04:09:00


Re: Drupal deployment/testing/don't-how-to-call it tool#4
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.

posted date: 2008-12-18 04:20:00


Re: Drupal deployment/testing/don't-how-to-call it tool#5
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.

posted date: 2008-12-18 08:02:00


Re: Drupal deployment/testing/don't-how-to-call it tool#6
The problem with Drupal is that nearly everything is stored in the DB and it's often difficult to distinguish configuration, content and 'disposable stuff' (caches, logs, etc). To make it more difficult, you often have user generated content using the same ID sequences as 'in-house' material.

posted date: 2008-12-18 09:13:00


Re: Drupal deployment/testing/don't-how-to-call it tool#7
Previously: Drupal Source Control Strategy?

posted date: 2008-12-18 09:31:00


Re: Drupal deployment/testing/don't-how-to-call it tool#8
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.

posted date: 2009-01-17 20:07:00


select page: « 1 »
Copyright ©2008-2017 www.momige.com, all rights reserved.