SharePoint 2007 lacks configuration deployment mechanism

Recently I have attended a great presentation by Andrew Connell on Structured & Repeatable Approach to Building Microsoft Office SharePoint Solutions at Office Developer Conference. Andrew has presented the pros and cons of different approaches to SharePoint development. That presentation has made me once again think about the lack of a good mechanism for configuration deployment in SharePoint 2007. I mean, there are Features and Solutions which allow you to deploy various assets in a structured and repeatable manner but how are you supposed to deploy a complete Publishing Site? SharePoint 2007 introduced the concept of Solutions and Features which could be compared to installers for desktop applications. Solutions allow you to wrap up some custom functionality you have developed while Features will make it possible to fragment it as granular as you want. Depending on the functionality you have created, you can scope your Feature either to the whole Farm or a particular Web Application, Site Collection or Site. As for the contents, a Feature can contain a horizontal piece of functionality like one Web Part displaying weather information or a vertical piece of the complete solution like Content Types or Chrome. All that is available using the standard SharePoint functionality. But imagine that you have developed all these assets and have put them on all the right places. In other words: you have configured the complete Site Collection. You are very likely to do this in real life scenarios: especially while working on Web Content Management (WCM) solutions where it’s all about the structure, chrome and right settings. There are some possible approaches you would tend to try. First of all using you could try the Backup & Restore mechanism: everything you see at your dev machine will get copied to the test, accept and production environment, but I mean everything. Are you sure you want to do this? This particular approach doesn’t leverage the structured & repeatable deployment concept for sure. And what about being in control of what actually gets deployed? Are you sure that there are no hard-coded or guid-based references somewhere in your environment? To tell you the truth: you can’t be sure - especially after a few weeks of development. There are however, some third party backup tools, which provide much more granularity level while making the backup. The problem with a backup is that it’s a binary file. You know what your backup contains right now, but will you still know it over a half year? Will your fellow developers know it when you will be working on another project a half year later? I doubt it. Another approach, available within the standard functionality package of SharePoint, is the Content Deployment model. It does seem like a plausible solution… unless you have worked with it at least once. Eventually it turns out, that it doesn’t provide the overview and flexibility you might want for structured and repeatable deployment of your work. Furthermore it’s not perfect, it’s not even close to, to be honest. I have spoken to many people who have worked with it, and they weren’t as positive about it as you would like them to be, while looking for a solution to deploy your configuration as structured as you deploy your assets. If you are a developer, and agree with me at least a little, and with no other possibilities left out there, you might want to just code it all. The SharePoint Object Model is really huge and it allows you to programmatically create and configure really a lot of settings you would configure manually. Why not create a separate Feature with a custom Feature Receiver which would take care of all these settings? Let me tell you why: the configuration of a SharePoint site can get big, and I mean big. Just recently I have worked on a WCM project for one of our customers, where we not only had to deploy completely pre-configured site as defined in the functional requirements, interaction design and graphical design all together but we had to cover the content migration from the old web site as well: almost 700 Publishing Pages plus images and attachments! I don’t believe that you would create a custom FeatureReceiver deploying it for you, because you wouldn’t. Feature receivers and parametrized Features are great but only if you want to initially set some various settings. Programming the configuration wouldn’t do the job because it’s inefficient (compare the time you need to create a Site Collection with a few sub Sites and set some basic configuration like navigation and doing exactly the same using code and testing it if it works correctly - even if you use Refactor Tools for SharePoint Developers) and you will lose the overview after creating a few sites and configuring them. I just don’t believe in such an approach - even if you found a really clever way of commenting your code so that everyone in your team knows what the configuration actually is and will be able to deploy the same assets with slightly changed configuration after over a half year without spitting through some manual or comments bush for a day or two before. Deploying configuration in SharePoint preserving the concept of structured and repeatable deployment is very important in many environments - in particular within some bigger organizations and in very particular if SharePoint is going to support the core business processes. These organization require their IT departments to be in control of what’s being deployed, what the contents are, being able to prove that these contents are indeed what they are supposed to be and being able to review all this information over any amount of time. Because it is important, I believe that almost every developer has found his own way to deal with it: either creating some step-by-step configuration manuals, using PowerShell scripting or anything else out there. So did we, here at Imtech ICT Business Solutions: it’s called OneClickDeployment Studio and I promise to tell you more about it really soon. And what’s your approach to the structured, repeatable and in control configuration deployment in SharePoint 2007? Technorati Tags: SharePoint 2007, SharePoint, MOSS, Deployment, Development