CiviCRM Community Forums (archive)

In the Drupal community there's a fair bit of discussion on how to make it easy to develop updates of your site on a development or staging server, and move those changes forward to a production server.  As I was thinking about this for the Drupal part of our site, it occurred to me that I'll have to manage it for CiviCRM as well.

Here's a sketch of the problem: if all functionality of your site is defined in code, deploying a new version is easy: you check it into source control, and check out the changes on the production server. But in practice, much of the site's setup is stored in the database--the database contains both "configuration" (setup of contribution forms, custom data fields, etc.) and "content" (actual contact and contribution data).  So if you start site revision work from a copy of the main site and make configuration changes, you then want to copy the database forward to the production server. But the DB on the production server has accumulated new changes to contacts, contributions, etc that you don't want to lose.

In the Drupal world, the "default" way to deal with this is to carefully record all your config actions as you do them on the staging server, then do all the same things again (by hand) on the production server. This is tedious and error-prone, and means you should really test everything all over again to make sure you got it right.

A handful of proposals have popped up to deal with this--e.g. segmenting the space of primary keys so that each server can make changes in its own "key space" and records can be copied without clobbering anything.

Is there any thinking already about this problem in the CiviCRM world?

Thanks.

Maarten.

PS: links to some Drupal discussions, blog posts, etc. are here:
http://del.icio.us/thinkling/drupal+deployment