SharePoint’s Content Deployment Engine

I recently went through the exercise of setting up Content Deployment in a client environment based on the information in an excellent post from Jackie Bodine.  (Looking at it with the Way Back Machine let me see the images, which were broken in the current post.)

For this client (as with almost all clients that I work with), we have a lot of Data View Web Parts (DVWPs) exposing content stored in lists of various types throughout the Site Collection.

What did I learn?  Well, for this client, it seemed like we had two pretty solid options.  Let me see if I can get them outlined well enough here:

Publish to Staging, Deploy to Production

This seemed to be the preferred method.  The way this would work is as follows:

• Pages and structures would be developed on Development.
• When things were ready, we would move them to Staging.  (This could be through Content Deployment or manually.  I think manually is the better idea in most cases, as you’d know exactly what you are moving.)
• SharePoint Designer-based workflows would be built and run in Staging.  (There is no need for the workflows to deploy and run in Production, as all content contribution and management would happen in Staging.)
• Users would publish content to Staging.  This would need to be ALL content for the Content Deployment process to work properly.
• Once content is published and approved, Content Deployment would pick it up and deploy it to Production on a configurable schedule.
• Production would be read only for all users (other than administrators).

Publish to Production

• Pages and structures would be developed on Development.
• When things are ready, we would move them to Staging.  (This could be through Content Deployment or manually.  I think manually is the better idea in most cases, as you’d know exactly what you are moving.)
• Staging would be used for QA only.
• Once things seemed OK, we would move them to Production.  (This could be through Content Deployment or manually.  I think manually is the better idea in most cases, as you’d know exactly what you are moving.)
• SharePoint Designer-based workflows would be built and run in Production.
• Users would publish content to Production.  No Content Deployment required.  However, we’d still have an approval process which would prevent content from being visible unless it was approved.
• Production would be configured for the appropriate permissions based on user role.

In the end, we decided not to go with either version for a couple of reasons.  First, the out of the box Content Deployment engine didn’t give us enough granularity.  It wants to work on the site level.  Second, we were told by the hosting provider that we couldn’t touch Staging or Production with SharePoint Designer.

In the end, it was clear the Content Deployment is actually pretty good and not that hard to set up.  It would make good sense in situations where the number of contributors is very low and the content is mostly page-based.  However, where most of the content is list based, exposed though DVWPs, and everyone is a contributor, it makes less sense.