Content deployment/merge strategies best practices

Question

We have a live site that has a fairly good amount of updates every day, mostly the business users make these changes.

Our development team is also underway making big changes to the code (including some refactoring, which may require re-adding webparts and we have several webparts in site pages), upgrading to proper 2010 styling, master pages, page layouts etc in our dev servers.

Pretty soon the dev and prod content database are going to be completely different. What is the best practice to merge these?

One way I could think of is that dev should work on a baseline prod database; make code changes; freeze prod; merge the content changes from prod to dev; replace prod with the one in dev. (I'm simplifying with only two servers, but of course we have staging servers too).

Looks very round about, but is there any other way?

Answer 1

This is the perennial problem, and not just with SharePoint, of dealing with content changes and development which work on different timescales. For SharePoint, the "best practice" is to use the feature framework and web solution packages to deploy all code changes, so that deployment is a completely automated process.

Having done this, there are many solutions to the problem of where to make content changes and how to go live with code changes. These involve all manner of staging servers, duplicated live and 'preview' environments, test servers and a host of content deployment strategies. It all depends on the nature of the content, the various timescales and the service level obligations.

In your case you probably want to keep your copy of the live content database on your test environment reasonably fresh. When you are ready to release, do a content freeze and do your backups. If you think there is a chance of content changes breaking your code then restore the latest content into your test environment and do a regression test. Deploy your code to live, and after doing your checks you can resume content updates.