39

What is the best procedure for merging work done on a development copy of a site to the live production copy? Often times there has been a lot of new content added to the site since development started on the newest features. And most additions to a site will involve database changes. So copying any new files is easy, but what about the database? How do you merge your changes with the existing production database without losing new content that was added since the last time you updated the production site? Are there any modules that help with this?

Improve this question
1
  • 2
    Remove confusion: Merge & migrate are two different words. You've used both in your question. If live site is empty, you need to migrate development copy to live site/host. If live site already has contents, there's need to merge new contents from development copy to live site (Merging is somewhat difficult). What do you need to do?
    – user931
    Commented Mar 3, 2011 at 1:02

3 Answers 3

Reset to default
16

For content types, views, and structure changes on the dev site look at using Features to export the database to code.

For content migration there are many options, but not a single solid solution. One example is the Deployment suite.

Improve this answer
1
  • the Demployment suite definitely looks interesting, though it is still in Dev (not even a Beta just yet). Have you used it yourself? Do you know of anything it wouldn't cover?
    – Chaulky
    Commented Mar 3, 2011 at 0:49
2

I've adopted basically two schools of thought here (a 3rd school of thought, doing database diffs, I won't discuss because the complexity is quite high).

1) Deploy by dropping the production database, and importing a mysqldump of the development database. Optionally, run a regex find/replace beforehand on any hard-coded absolute links which reference the dev URL in the SQL dump. After importing the dev db into prod, automatically run SQL statements (usually via script) afterwards to change any settings that are different for prod than dev (e.g., maybe you have in variables table some connection settings for connecting to external systems that you need to change to point at prod external systems instead of at the dev version).

2) Use the Features module, as mentioned by budda, for admin settings, and use the Node Export module for content export/import in combination with the Delete All module. So workflow is:

  1. use node_export and features to export nodes/features to files
  2. Optionally (and hopefully) version control
  3. Load files on prod system
  4. Use drush or admin interface to load features
  5. Use drush delete-all or admin interface to delete all nodes of the types you want to import
  6. Use drush ne-import or the admin interface to import the nodes from the nodes file you exported.

One note, I would highly suggest adopting a standard workflow, where content goes one direction only. Either Dev -> Prod or Prod -> Dev (I prefer this one).

I've done this, and am doing this on some big systems, with fairly good results, but there will always be many ways to slice this apple, choose whichever way works best for you.

Improve this answer
2
  • In option 1, how are you recreating the content that has been added to the live site that isn't in the dev site? It seems like you're overwriting all of it with the dev db and then maybe changing some settings/variables. Also, which school of thought are you using on your sites currently? Any pros and cons to each approach?
    – Chaulky
    Commented Mar 3, 2011 at 1:01
  • In option 1, we now use node_export to regularly send over the content (having removed previous content). We used to make content changes on both dev and prod. This is actually a common scenario at a few places I've seen, though obviously not ideal. This is why I add, adopt a direction and stick with it, either content goes dev -> prod or prod -> dev, but try not to do both. And yes, we basically overwrite, although more like erase and rebuild. At my new job we do #2, at my old job we did #1 but are moving to #2 (im still consulting for them).
    – coderintherye
    Commented Mar 3, 2011 at 19:51
1

Dump databases of live site copy & development copy of site in SQL file (use same parameters & settings for both dumps).
Then, compare both SQL files using a small comparison tool ExamDiff. It'll display file differences side-by-side with different colors. You can directly jump to the differences also (without scrolling). Examine the differences & add/edit lines to SQL file of live site. Make sure there's no absolute path/URL of development environment in that file. That's done! Time to restore the database for live site.
Make your life easier: In first step, dump only those tables which are changed. For example, if you've edited a module in development copy which targets a separate table, dump only this table. If you're not sure about particular table, whole database dump is fine.

Improve this answer
1
  • This technique has severe limitations in some important circumstances. For example, if the development site has new nodes, then your two databases will both contain entries with the same node ids, and it will not be possible to resolve references and merge them from a text dump of the sql database. This sort of operation is better handled via features and deploy, as mentioned in other answers.
    – greg_1_anderson
    Commented Mar 30, 2012 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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