One of the biggest gaps in Microsoft Office SharePoint Server 2007 is the Site Deployment component. This component is, quite frankly, buggy and feature incomplete. It is not production ready and does not address most site deployment configurations seen in the real world.

To start off, Microsoft’s vision is very short-sited when it comes to how to develop and deploy SharePoint content. The idea that you will have a fully functional development, stage, and production environment is foreign to the current SharePoint vision. At a high level, you would develop your SharePoint components (i.e., WebParts) in a development environment, and port that application to your “stage” environment. Then, using Content Deployment, would push that environment to your production environment.

But what about Web Content Management? And, how does that affect this scenario.

In short… it affects it dramatically. First of all, in the Web Content Management (WCM) world, the idea of developing separated to your functional look and feel is pure fiction. In today’s day and age, it is vital that we see how content looks and perform unit testing on it before we look to begin integrating into other environments.

On one project I worked, the client was a long term user of Microsoft’s Content Management Server 2002. Using the upgrade wizard, the site content (all 2.5GB of it) was ported to MOSS 2007. Once on this platform, we quickly realized that we needed a workable solution to the “team development” environment situation. How does one create new content, mixed with SharePoint configuration settings, and integrated code without having to rebuild each on all developer workstations? With Microsoft’s recommended approach, you can see how this would quickly become a nightmare.

Our solution was simple, but led to a new complication we did not anticipate. We created a development SharePoint Farm. We had a SharePoint Development server and we basically took each development image and joined it to that Farm. Use Team Foundation Services (TFS) to manage code, and presto, we appeared to be in business.

After a surprisingly short period of time, we had our first site upgraded and ready to begin testing. Well, like any good programming shop, the next step was to move our work to the “Stage” environment so that we could point our testers at it and let them do their (evil) job of picking apart our failures.

Well, it became quickly apparent that the Content Deployment tool that is included in Central Admin was not really going to live up to what it promised. Over the period of 7 days, we attempted to do content deployment to our Stage environment to no avail. We tried full deployments, we tried incremental. We tried partial and complete content bases. We finally just settled on a backup / restore solution and decided to revisit this later.

As testing progressed, we eventually migrated a portion of our site to production under the new platform. Woo Hoo! Well, not exactly.

We wound up painting ourselves into a corner here. You see, once we went live with this content, our stage and development environments would never be synchronized to a level that we could simply backup and restore our environments to deploy. We needed a content deployment option, and we needed one fast.

Well, with no other option to think of, we opened a Premier Support ticket with MS. After a week of the usual ups and downs of recreating the problem, we got confirmation this was a valid issue from MS. The only problem was that the hotfix was schedule way past our drop dead launch date for new content deployment.

Well, we went down the path of writing our own content deployment application using the deployment API’s included with SharePoint. This got us about 90% of the way towards where we were going, but we still had some issues with key conflicts, etc. Using STSAdm.exe, we were able to bridge the last 10% and were on our way.

As a final note to this article, I have it on good authority that sometime this week, Microsoft will be releasing a hotfix to address the primary bug that we faced:

" Violation of PRIMARY KEY constraint 'PK__#ExportObjects____XXXXXX'. Cannot insert duplicate key in object 'dbo.#ExportObjects "

Once we have the details on that fix, I’ll post them here.

Also, for anyone interested, I hear rumors they are planning on revamping the entire Content Deployment piece scheduled tentatively for May of this year. I’ll keep you informed as I learn more myself.