Partager via

To Content Deployment or not to Content Deployment, that is the question

  • Article

As you probably have read, I ran into a couple issues lately with Content Deployment (Slow with SP1?, major/minor versions, AAM on Central Administration, specified file already in used, links not fixed at destination, TCP connection closed, the requirement to create a publishing site + delete + create a blank site) along with a few others that I haven't post on yet (since I don't know how to fix them yet!).  Errors such as :

  • Save Conflict Your changes conflict with those made concurrently by another user
  • You cannot perform this action on a checked out document
  • Timed out (at importing)
  • Object reference not set (during export, I noticed "memory corrupt" exceptions close to the same time it fails; that problem might be fixed with .NET Framework 2.0)
  • Cannot delete file since it does not exist
  • Cannot create the file since it already exists at the destination
  • The SQL Transaction logs are growing up very fast (I had a development environment with a 100 MB web site running a Full Content Deployment every day, yes I forgot I had activated it!, after a month, the transaction log was at 356 GB <-- yes GB and no I don't have backups for that database so that's why the log was so big).  it turns out that the Full Content Deployment runs so many queries that the transaction log grows pretty fast if you have Full Recovery (which is required for database mirroring).
  • Web parts added on a page may not always be there at the destination
  • and then some more issues that I forgot over time

 

Most of these are either errors that you can happily forget, some are errors that may or may not happen if you restart the deployment, some are "user created" but shouldn't happen, and some I had to create workarounds since no fixes are scheduled.  When you look at this, I cannot say that Content Deployment is reliable for that environment.  Unfortunately, it's not only for that environment.  I was able to experience these random issues with an OOB publishing site that didn't have any added content!

 

I'm in great need of inspiration from the product group on this one because I have a hard time saying that there won't be any issues with Content Deployment to a customer.  So I started musing on why we are using Content Deployment in the first place, after all, it's for an Intranet scenario.  Normally, you need Content Deployment because you want to have a staging site collection (or farm).  Especially for an Internet scenario, you probably want to put the authoring in a DMZ or even internally with your authenticated users secured.  Otherwise, you may simply want to limit your authors so that they cannot bring have an error in production easily and you want to validate everything before a content deployment.

 

While these are still true, one of my environment is for an Intranet portal so the DMZ point isn't important as the users are authenticated everywhere on the site (and it's personalized).  All that's really left are the authors "screwing up" the web site!  However, I've seen scenarios where Incremental content deployments are running every 30 minutes ... that doesn't let you validate everything before now, does it?  Also, you can always approve a page right before a deployment and still have the issue.  So, if you don't need a DMZ, why should it be a best practice to have a staging farm?

 

Let's check what an author can really do to "break" a web site?

 

The author forgot to approve images or linked documents used in the published page.

First of all, they can still run into that issue if they approve the page right before the Content Deployment.  2nd, is content approval required for those images & documents?  often case, it's probably not.  If it is , then there isn't much to do but have a more rigorous approval process. Otherwise,  Solution : don't use the default site definition and create yours where content approval is not required on documents & images (but still is on pages).  If you are already deployed, create a feature to set the parameters and staple it to the definitions you used.

 

The author needs to see the page as a visitor prior to approving it.

Solution : there is an option available through the toolbar under where you can view the page even if it's not approved.

 

What if the author adds something that shouldn't be there?

Well that's why "Approval" is still required.  If you activated the Review Workflow because it's the right thing to do but that approving simply means clicking the button, something's not right.  I often case have the question "why can't we approve multiple pages at once?".  Reality is that they might need "Publishing" instead of approving if they aren't going to check the pages.  To get back on track, the solution is to define better workflows and to have more rigorous approvers.  It's also good to know that a workflow with multiple & sequential approvers do not actually require "Approvers" permissions, only the last one in the list who will do the actual transition from archived to published.  Don't forget that authors are also accountable.  While that may not be much once a "negative" page has been sent online, simply knowing this will likely make them think twice before approving or publishing content.

 

Can the performance be impacted since authoring pages are usually much bigger?

While it's true that editing will use more resources on the servers, the solution is simple : dedicate one of your farm servers for your editors where their DNS directs them there directly and this server isn't returned by the load balancer.  If they are on the same DNS server, then you could also create an Alternate Access Mapping to that site, thus a different DNS, that only the authors access.

 

There's no need for quick deploy anymore

Well that's not a problem but directly a solution where Quick Deploy only works for publishing pages ... if that page references an image or a document, it won't be deployed at the same time.  While I'm guessing the feature's meant for updating text on an existing page, it's still annoying for authors to be able to deploy a page but not its images.

 

Food for thoughts

While I obviously "feel safer" to have a staging/authoring farm, in an intranet portal scenario, reality is that those portals are often case close to a collaboration portal without collaboration.  What I mean by that is that you are sharing information and documents while you don't need users to collaborate on it.  If you thought of it as Collaboration, you wouldn't consider using Content Deployment so why should it be different for a WCM intranet portal with no DMZ requirements?  I'm still taking about a portal that's viewed by 10-50k people a day.  Any comments?

 

Maxime

Comments