What is best practice for syncing a local dev site with a live production site when your live database is constantly changing?

From what I have read there are two possibilities:

  1. Replicate changes made in dev manually on your production site. This seems like something you would only want to do with fairly limited changes that I can make while the site is down for maintenance and users are unable to make any changes to the production database. I can imagine that it can make it tough to make more complex updates/changes. I have done this in the past with simple changes/updates to modules and so on.
  2. Migrate the test site into production, with the site in maintenance, and synchronize the databases. This option seems more like the way to go for bigger jobs, as long as I can synchronize the databases somehow.

That seems to assume that your production site is basically static and the database will not change much at all when you are making changes on your test site.

However, I am working on a batch of improvements for site that has daily activity (new content, users, transactions, comments etc.). These changes are taking time to set up and test.

I found this comment on Drupal.org https://drupal.org/comment/4511654#comment-4511654

It addresses my situation, but is there any better way to go about this or a more detailed guide/how-to? Or should I be breaking things up into smaller and more manageable chunks -- that way seems time consuming.

  • Welcome to Drupal Answers. Unfortunately, this is a really broad topic, so I have to close it. There are really too many possibilities, and a lot of them depend on your situation. The topic has also come up numerous times here. A search will bring up some good questions with answers. If you need help with a particular solution that hasn't been addressed before, please feel free to ask it. – mpdonadio Apr 1 '14 at 18:06

Here are some good ideas to use:

1.) Backup and Migrate module. Before doing any local changes migrate the production database down to your local environment

2.) Features. Make all your content type into specific features. Include content types, views, context, and any other thing that can be put into features. This will allow you to make content type changes and almost ANYTHING on the site and simply roll it as a feature. When its uploaded to the production environment you simply revert the features, and bam they are there.

3.) Stongarm and Diff are additional modules to use with features. They allow to see whats different from the site and the feature, and strongarm allows variable exports into features.

3.) GIT or SVN. Use git or svn to roll to production and keep your code base on track. With major features differences use a branch to complete work and merge it into the trunk. This will allow you to development bigger features, but also give you the ability to make bug fixes that can be sent up in a roll.

4.) RSYNC. Most of the time sites/default/files or CMS uploaded files are not in your repository. Use rsync to sync the production files to your local. Or simply use FTP

5.) Use drush up to update your modules it will keep your subversion or git in tact. It will also attempt to update your database.

| improve this answer | |

Have you worked on deploy module before... really reduce manual process by its smart functionality.

See the below mentioned modules. https://drupal.org/project/deploy_services_clienthttps://drupal.org/project/deploy

Read more about deployment configuration https://drupal.org/node/408774

hope it helps

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.