If you would like to discuss anything, please contact me via email: Howard.Bayliss@sequence.co.uk

Monday, February 21, 2011

SharePoint Solution and Authored Artifact Development

Microsoft produced a useful article regarding designers and developers working together on SharePoint projects (albeit it's for MOSS, not SharePoint 2010).

However, the article does leave an unanswered question, which I address below.....

Based on the Microsoft article, our approach is this:
  1. All developers and designers have their own virtual machine, running an independent SharePoint farm.

  2. All assembly and artifact development takes place within Visual Studio - SharePoint Designer is not used.

  3. Team Foundation Server (TFS) is the only repository for source code.
We like this approach because:
  1. We can comply with ISO standards for source-control.

  2. Master Pages and Page Layouts are deployed in an uncustomised state.

However, consider this scenario: Developer A needs to create a content roll-up which rolls-up content from a deep site structure. In order to create the roll-up, Developer A needs to create all of the content on their own farm. Once they've checked-in the roll-up code into TFS, other developers can use the roll-up in their farms, but only after they have re-created the site structure - and that could take a long time to create.

In addition, suppose Developer A creates a roll-up that targets a particular list (by the list GUID). How do you ensure that the list is created with the same GUID on all farms?

What's needed is an easy way for content to be replicated between all of the farms.

There are several possible solutions to this:

  1. Back-up the content database in one farm and restore it to all of the other farms. This is not ideal as the process would delete any work-in-progress-content that a developer had created for their own use.

  2. Use SharePoint's built-in Content Deployment process. This will distribute newly created content between the farms, and doesn't have the "delete" issue described in the last point. However, as we mostly work with SharePoint Publishing sites, we have an issue in that you can only deploy content to a Publishing site collection that has not already had a site definition applied. This means you need a "master" farm, where all content is created, and from where content is deployed. This is not an ideal situation when you have multiple developers who need to create content and test locally on their own farm.

  3. Use "stsadm -o export" to package content to a file, which can be re-imported into another farm. This is our preferred method as it avoids the issues listed above. Exported file packages can be put into a shared folder or TFS, depending on your requirements.

No comments:

Post a Comment