Configuration provisioning is very important in structured and repeatable deployment of SharePoint 2007 solutions. While solutions which target intranet environments, tend to be more dynamic and consist mostly of assets, delivering Internet-facing sites using SharePoint 2007 is more about delivering a complete experience: preferably a preconfigured environment with all the assets on the right places. While SharePoint 2007 introduces Solutions and Feature - a framework for deploying assets, it doesn’t provide a flexible mechanism for structured and repeatable configuration deployment. To be able to deploy SharePoint 2007 solutions in a fully structured and repeatable manner, we have designed our own approach for deploying configuration here at Imtech ICT Velocity.

Background

At the end of 2006 we have started working with SharePoint 2007. Because of our several years experience in implementing Web Content Management (WCM) Systems, we have decided to focus on SharePoint 2007 WCM solutions at first. Right from the beginning we have decided to embrace the concept of deployment packages: Solutions and Features. Quite fast we have discovered, that while SharePoint 2007 provides great flexibility, comparing to SPS 2003, it still lacks a flexible mechanism for deploying the configuration. Looking for a solution we have researched the way SharePoint 2007 works. We have looked at how the Features and Solutions work, what their possibilities and limitations are and where assets stop and the configuration begins. From the very beginning of thinking on our own approach of deploying the configuration, we knew, that we didn’t want to substitute SharePoint 2007 framework with our own. Instead, we wanted to fill the gap and improve the efficiency of our work. SharePoint 2007 gives you the possibility of extending Features with custom code. Because almost everything what can be done using the SharePoint GUI, can be achieved using the object model you could theoretically provision your configuration using Feature Receivers. The biggest downside of this approach is embedding the structure and configuration in code. While it might be clear during the initial deployment, are you sure that it will remain that way over a year? Separating the actual code and custom functionality from the structure and configuration was one of the first requirements for our approach. Furthermore we wanted to keep it simple, lightweight and make it leverage the SharePoint 2007 object model structure as much as possible. After analyzing all these requirements, we figured out how our framework should look like.

Definitions

To fully benefit from our solution we have divided the deployment into assets and configuration. We call assets all the custom pieces either developed or designed by a project team. A couple of common assets are Web Parts, assemblies, Page Layouts and Master Pages including their resources, custom application pages and resource files. When saying ‘Configuration’ we mean the persisted state of the particular assets or objects like: Web Part A with certain settings put on Publishing Page B for example. Configuration is of course a broader term because it’s not only about configuring the assets but SharePoint objects as well: imagine provisioning a Site Collection with a number of Sites all of which have the versioning settings, the navigation, the chrome and the available Site Templates and Page Layouts preconfigured. There is also the third part of deployment called content. The WSS team has made it a bit more difficult to us to use the term ‘Content’ while talking to our customers and other non-SharePoint professionals. Looking at the Content Management concept, content is the information you want to share with your visitors. All that information is being provided by the content editors during the life cycle of a web site. In general each Site Collection in SharePoint 2007 has its own content database. That database contains both configuration information, content and much much more. That’s why we have decided to keep it simple, both for our customers and ourselves and stick to the Content Management definition of content. When talking about provisioning content in SharePoint, we mean List Items and Publishing Pages. While designing our deployment solution we have made another very important choice. We have decided to leverage various deployment mechanisms provided by SharePoint 2007 (like provisioning Site Columns, Content Types and various assets) and focus on the parts left. Thanks to this decision we were able to benefit of the known concepts, existing best practices for deployment, and enhance the deployment process with our custom solution.

Solution

Nearly a year ago we have started developing the Imtech SharePoint OneClickDeployment Studio (OCD). Back then, called Imtech MOSS 2007 Content Structure Configurator (MCSC), the tool was provisioning only the sites tree: something you might know from the Publishing Portal Site Collection Template.   At the time we started working on OCD there was little to none documentation on the Content Deployment Prime. To have the required atomic level of control on deploying the configuration we have chosen for using the SharePoint Object Model for communicating with SharePoint 2007 and we have developed our own XML format to store the configuration. From the very beginning we support two UI’s for OCD. The first one is a set of custom STSADM commands which allow us leverage the concept of automated deployment. While we have started with the export and configure functionality, we have extended these commands with new functionality and incorporate some options to provide a more granular control of the configuration export. Imtech SharePoint OneClickDeployment Studio is also incorporated inside SharePoint UI. Upon the installation there is a Site Actions menu available which allows less technical users like consultants and designers to either export or configure SharePoint 2007 configuration. Since we added support for Publishing Pages we have extended the WSS GUI (as we call it) with an extra button residing on the Publishing Console which allows us to export complete Publishing Page including content, Web Parts and any other properties we support. When we started using OCD in our projects it didn’t support many configuration settings. Delivering a single XML file or two was sufficient to persist all the supported properties. While OCD has evolved during the last year we needed to find a better solution than delivering separate XML files. I still remember a project for one of our customers when we included content migration from the old web site. The deployment package consisted of nearly 600 OCD XML files! While looking at the deployment deliverables we have decided to store the OCD XML files alongside other assets inside the .wsp file. In order to provide OCD with some additional information about the deployment target and order of running the XML files, we have developed OCD Manifest: an XML file containing both a playlist of all XML files and some general properties.

Our experience with OCD

After a week of working with the first version of MCSC we have discovered its potential and we have decided to make it an integral part of all our projects. As we are a projects oriented organization, we have decided not to develop OCD as a product. Instead we have decided to use it in our projects and extend it with the missing functionality required to automatically deploy the project we were working on. This choice worked out pretty well for us. After a year of working with OCD we cover now quite a big part of the SharePoint Object Model. We don’t cover it all and we are strict in making our choice in whether a particular part of the Object Model should or should not be supported by OCD. Keeping OCD simple allows us to extend it in the short amount of time we have during a project and benefit of our effort at the end of it. One Click Deployment is not only a tool. It’s a whole concept of how we approach development and deployment in SharePoint 2007. Our main goal was supporting structured and repeatable deployment of SharePoint solutions: not only of the assets but of the configuration as well. Our approach allows us to do the Deployment Driven Development: each work package within the project we finish ends up in the .wsp and OCD XML. By doing that we are able to provide our customers an overview of the overall project progress without any extra effort besides deploying the project to a SharePoint environment.

Benefits

After having used OCD in many projects during the last year we have discovered the following benefits:

Separating configuration from code

By using an XML document to describe the configuration we don’t need to code it inside Feature Receivers or custom deployment assemblies anymore. We have more overview about the whole solution and we can modify pieces of the configuration without having to rebuild the code.

”Extended” Features and Solutions framework

Because we have chosen to base the OCD XML on the SharePoint Object Model it is easy for us to track the configuration and incorporate newly developed work packages into OCD deployment scripts. OCD extends the Features and Solutions framework by providing a structured and repeatable mechanism for configuration deployment.

Speed

By using the intellisense for the OCD XML, code snippets and by reusing various configuration parts we are able to develop quicker and focus on the custom functionality instead of the routine work. Instead of creating 10 sites with the same or similar settings we can create just one, export it to XML and then copy the XML modifying the XML where necessary.

Source control

Because the configuration of our solution is described using XML we can store it in source control. By doing that we are able to track both the overall progress of a project and changes done to the configuration. Being able to store the configuration in source control gives the same benefit we all know from storing the code in source control.

Collaboration on configuration

Thanks to OCD we are able to collaborate not only on the custom code we are developing but on the configuration as well. OCD enables us to work focused on atomic work packages instead of larger functional areas as defined by SharePoint. By deploying pieces of the OCD XML we are able to work on a certain piece of a web site with multiple developers without a separate integration environment.

Structured and repeatable deployment

Last but not least: it’s all about structured and repeatable deployment. During the development stage of a project we are able to deploy our work and confirm that it works according to the specifications. During the deployment process we delete the existing Site Collection and deploy the whole solution from scratch. By doing that we are sure that we don’t deploy anything else than either developed in our custom code or described in the OCD XML.

Proven technology

So far we have used OCD in all of our SharePoint projects. We have noticed that it allows us to deploy our solutions in a fully structured and repeatable way. Next to that extra piece of control on deployment we gained some other benefits like reusing common configuration settings and cloning similar parts of the solution. While we have put a lot of effort in designing and developing OCD so it would become a great deployment strategy it is now, it pays back in a great way allowing us – developers to focus on the challenges instead of routine work. In the coming few months we will be working on improving the performance, the overall quality and extending OCD with some new features.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WSS