Drupal in Subversion
I'm not sure whether this qualifies as a "support" question or a point of discussion, but I'm desperately curious about strategies anyone has used to develop and maintain drupal sites in version control and with a QA process. In most professional software and website development projects (okay, "most" is maybe an exaggeration) you have a certain structure, built around QA and version control.
* A development site, where you work;
* A staging site, to which you publish changes for final testing;
* A QA testing process;
* A live site.
If you've got a drupal site and you want to upgrade it or add to it or otherwise work on it, without disrupting the live site, you need that staging environment, but since so many core settings are stored in the database you have to choose between rolling back content, manually updating the changed settings, or, somehow, separating out the relevant tables and only migrating changes to the settings.
Has anyone ironed out a smart formula for accomplishing this? Please share!
You could....
This may not be the "best" solution, but it would work, and I use this method.
You could have 2 different installs of drupal, one for your "live" site and one for your testing site. Then just mirror your content. I have a testing subdomain that has all of the same content as the live site, just mirrored.
I know that this is not the best solution, but it does work.
Ian
Yep
I do this with two sites (testing and production).
First I make a clean install with the modules and 3rd party software I need.
Then I import this into Subversion, except the configuration files.
Then I delete the directory and check out from subversion, so that I am working within subversion.
On the production server I check out a copy as well and drop in the correct configuration files.
Whenever I make changes I do them on the testing server, I have people try it out there, and then I commit to subversion.
On the production server I simply do an update. If I get reports of problems there I just revert to the previous version until I can figure it out.
The database changes, which happen extremely rarely, I usually transfer manually. If you do more stuff in the database then you should create a script that dumps the relevant tables from the database and stores that dump-file in subversion. So instead of just doing a subversion update you do an update and read the database update.
Make sure to block .svn through .htaccess or similar devices.
Blocking access to .svn
For those curious, I added this blurb to the virtualhost definition for my site in httpd.conf to block apache access to all .svn directories.
<Directory ~ "\.svn">Order allow,deny
Deny from all
</Directory>
Note the Directory directive can not go in .htaccess files, only httpd.conf.
Ben West
One solution
I also posted my question to a list that did some version control on a Drupal site and came up with this response:
Ah yes. I'm curious too (about a good way of doing this).
We didn't do the database stuff in subversion. I think we came up with a
brilliant solution given the limitations of Drupal - but otherwise it would be
considered badly flawed.
The main problem is that Drupal does not have a programmatic interface to many
of the settings functions that change data in the database. If there was a way
to script that gui/setting changes than we could commit those scripts and run
them when updating. Since there isn't we did this approach:
* We created scripts that synchronized databases:
Between the live site and the staging site
Between the staging site and our individual development sites
* When making a change we would:
- Sync the live to staging db
- Sync the staging to dev db
- By hand make db changes to dev db and write them down (and split between
db changes that have to be made *before* the code is in place
and changes that have to be made *after* code is in place)
- Make coding changes
- Commit coding changes
- Make *before* db changes on staging db
- Update code
- Make *after* db changes on staging db
- Test
- Repeat on live server
I wish there was a better way!!
I havent done this, because
I havent done this, because I dont have this need myself, but Drupal does a nice job of separating configuration and user generated content into different tables.
If you just dump the correct tables (most of them, but not node and users, for example) and read them in, and update the code with the same command, I doubt you will run into problems very often.
The whole process shouldnt take more than two seconds, if you kill Apache for this period you can at surely replace the "*before* db" and "*after* db" with a single operation.
Script for test-to-production database migration
I'm releasing a new script that does this. It migrates all configuration changes from a development/test site to a production site while leaving its content alone.
See Migraine.
The Drupal Migraine script
The Drupal Migraine script is constructed to help in these matters: http://shearersoftware.com/software/server-administration/migraine/
Try it out and please do post back your experiences using it.
Cheers!