Strategies for moving features from stage to production?

Hi morisy,

I'm curious how you've been migrating changes from your development site to your live site. My guess from the symptom you're trying to avoid is that

1. The two sites (dev. and prod.) are set up as independent instances,
2. You make an SQL export from the dev site, and then
3. Overwrite the database on the production site with the dev. export.

Is this accurate, or do you use a different process?

I would suggest that, while you're making changes on the dev site, keep track of the actions you're taking, modules you're adding, configuration settings you change, etc. When you get to the final setup for that particular change, document the final configuration. Then, manually make those changes on the production site. This method takes extra time as you'll be duplicating some work, but has the benefit of not needing to monkey around with databases (and messing things up on production if your dev SQL export includes changes to tables production relies on before you've upgraded or enabled particular modules). Further, you'll not be losing any content from prod.

There's other things you could do, including only exporting tables with changes, or setting up the dev server to share the content tables in the production site, but these both run the risk that, when you do SQL export/imports, you may overwrite the wrong data or miss exporting something and end up breaking your prod. site.

The safest way I've seen it done is to do the development on dev., write out a set of upgrade instructions for yourself, and then execute the upgrade instructions on prod. (and skip the SQL exporting altogether unless explicitly needed).

Just for the record, there's no need for two physical servers but rather two installs of Drupal with their own databases running in a single mySQL install. The development site would run off of subdomain like dev.yoursite.com with updates being sent to the production site when ready for release. The golden rule is that development should never be done on the production site unless you have nerves of steel and few years to loose off your life when everything goes "boom".

I've been thinking about a way to resolve this problem. Although this thread appears to be before the time of Features Module, which might solve some/most of these database update issues, I think a module that exists simply to "sync" database from staging/development to live might be useful. The question is, would it work? Is it possible to effectively track all database changes made on a development version of a Drupal site, and then sync those changes into the live Drupal site?

I think there are database hooks we could use to track every database operation, which could then be stored, prepared for syncing. The problem is that a collision will occur on some tables, such a node table, where the same nid may be in use on both the staging and live site and each refer to different content. I have an idea for how to resolve that. It involves assigning a globally unique Sync ID to each database query stored by the sync module. When the sync is run, it would check for conflicting primary keys, and it would then resolve that conflict by using the next available primary key. It would also need to roll that change out to any subsequent sync operations that involve that altered row.

My view of this issue is to basically look at database rows as roughly equivalent to files in a version control system. With this approach we need to insert/update/delete rows in the live database based on the change history in the staging/development database since the last update. I'm only thinking about upstream syncing at this point... I figure if we can solve how to sync the staging server with the live server, after the sync you could use Backup/Migrate module to copy back the updated database into the staging server, at which point a new cycle of development would start with new tracking in the sync module.