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.
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.
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.
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.
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.
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.
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.
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.
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