SharePoint Lessons Learned – Clearly Define a Deployment Baseline (Part 2)

In part 1 of this post I’ve talked about the principles behind the creation of a Deployment Baseline during the development of SharePoint based applications. In this post I’m going to talk about how we, at Collaboris. normally group and categorise the different artefacts to create this baseline.

This post assumes that you are familiar with the concepts of SharePoint Features, Site Definitions and Solution Packages. For a primer on these concepts please refer to this page on MSDN.

There has always been a lot of debate around the best way to deploy SharePoint applications. Some people do not like Site Definitions or Features and prefer to use Site Templates (.stp), others prefer xcopy deployment and others like me stick with Features and Site Definitions deployed using Solution Packages. I’m not going into that debate here, I’m simply going to describe the approach that we have been taking for the last few years without any regrets.

Like I’ve mentioned on the first post I’m strong believer in using the SharePoint Features and Solution Framework for the delivery of SharePoint applications. We normally try to deploy most of the artefacts via Features which are activated via Site Definitions and deployed using Solution Packages (WSP). One of the biggest advantages of using WSPs as a delivery mechanism is that SharePoint will automatically deploy the WSP contents to all Web Front End servers on the Farm.

We normally try to identify the deployment artefacts very early in the development lifecycle. Normally just after the initial requirements analysis. We use Mind Maps during this stage because they are very easy to produce and can quickly give you an high level overview of what needs to be delivered. We call these documents “Deployment Artefacts Maps” and we normally create two; one showing all the sites, pages, doc libraries and lists (see example below) and another with all the UI controls. These are dynamic documents that will evolve during the project lifecycle.

 

Example of a Deployment Artefact Map

 

These “Artefact Maps” together with a high level domain model (that helps me to understand the complexity of the data) allows us to size and cost the project from very early stages.

The next step is to group the artefacts and define a deployment strategy for each group. We normally organise them into into three major groups:

1. Infrastructure Artefacts (CSS, Style Images, Page Layouts, Site Columns, Master Pages, Content Types, List Templates, etc) – normally deployed via Features and CAML scripts and activated via Site Definitions (so that they are automatically activated when a site is created).
2. Configuration Artefacts ( Permissions, Navigation, Search Scopes etc) – deployed via features but using a mixture of CAML and custom code called from feature receivers to overcome some of the CAML limitations. This is were tools like SAF are most useful and can dramatically decrease the amount of effort require to deploy your application (SAF is a fully extendable XML framework that incorporates a series of custom actions that extend the functionality provided by CAML. For more information on SAF please follow this link ).
3. Content Artefacts (documents, page layout content, content images, lists content etc) – we normally subdivide this into 4 subcategories:

• Static Content – This is content that it will not change and you want to be there from day one (when the site is first deployed). We normally use a feature with CAML to deploy this.
• Sample Content – It’s a lot easier for business users to be given a site with some sample content that exemplifies how the site can be used. This content is deployed via a feature that can be manually activated by a site administrator.
• Test Content – normally created by the test team to cover all the different test scenarios. This content is created once and then manually activated by the test team (simply by activating a feature) in every test iteration.
• Dynamic/Business content – This is content normally created by business users (sometimes even when the site is still under development). We deploy this content using a SAF deployment action that uses the CMP API to provision the content. One very important thing here is that our feature will only provision content (list items or documents) into an already existing lists that has been created by an infrastructure feature (see point ‘1’ above). This way we clearly keep a separation between infrastructure (the list template and instance) and content. This separation also helps delimiting the areas of responsibility between IT and the Business (IT department is responsible for infrastructure artefacts and business is responsible for content artefacts ).

This was a very high level overview of how in Collaboris we define a Deployment Baseline. The next step will be the creation of a Visual Studio solution to implement the deployment packages defined in this Baseline. But more on that on a future post.