Managing the SDLC in Microsoft Office SharePoint Server 2007 and WSS

Author: Nick Kellett
August 1, 2007

SharePoint development can be difficult to manage because its whole philosophy seems to blur the software development lifecycle (SDLC). One of the big selling points of SharePoint is how it can shift the burden away from the Information Technology team's shoulders and empower business users. This is true: witness how simple it is to fire up SharePoint Designer and make changes to design or workflow; create your own lists and sites; upload documents to libraries and manage your own content publishing. All of this makes information workers' eyes light up.

The problem is, a lot of the changes that are made are hard for the IT team to replicate. If you get a call from an end user asking you to restore the special document library columns they created a month ago, what do you do? Not only are there a wide variety of software artifacts created during a SharePoint solution, but many of them are virtual and "live" in the SharePoint database itself! Many IT managers are worried about uncontrolled SharePoint development - what is called "SharePoint beneath every desk".

If this were change-managed in the traditional IT sense, there would be development environments, source code repositories, installation packages, regression testing, quality assurance...which while reassuring and reproducable is also a bottleneck and frustrating for end users who love the new flexibility and control they get with SharePoint.

So what's the middle ground? The jury's still out on this...but we're starting to see some best practices. One key document came out just the other day by Patrick Tisseghem of U2U fame. It's a first-class document outlining development considerations around SharePoint. The links to the document's two parts are here and here. There is also some documentation called "Under The Hood" which explains how Microsoft developed its Fantastic 40 templates and gives some great insight into what can be done with the platform. Read it here.

Key things the white papers touch on include the importance of applying the same principles of solution architecture, identifying and applying design patterns, and assessing the capabilities and limitations of technology that you would use on any software project. Perhaps the most important thing is to try and treat SharePoint with the discipline and process required for any major Enterprise application.

Part of that discipline includes keeping as many of your SharePoint customizations in your source code repository as possible. There are several tools to help you do this:

Site Templates

If you're a SharePoint Administrator the simplest way to get a copy of your site and its content is to save it as a Site Template. If you don't see the "Save as a site template" option you can manually navigate to it by using this url: "[full url to top-level site or subsite]/_layouts/savetmpl.aspx". On the Site Settings page the list of available site templates is found under the "Galleries" tab.

SharePoint Designer

SharePoint Designer makes it easy to customize sites, but here are some things to consider:

1. You can export the site as a web package, site backup, or site template for storage in source code repository or use on other sites. Microsoft gives a step-by-step outline of how this can be done here.
2. You may wish to restrict who can use the SharePoint Designer and what they can do with it. You can control the ability SharePoint Designer by modifying the Contributor Settings in SharePoint Designer. This can prevent the creation and modification of workflows, web parts, etc by default users who can only modify content in a webpart zone. This allows you to limit their contributions to essentially design decisions. To do this, load up SharePoint Designer as a site administrator, and change the settings in Site : Contributor Settings.

SharePoint Solution Generator

The SharePoint Solution Generator is part of the Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions released by Microsoft to help manage the creation and maintenance of WSS 3 sites. Serge van den Oever has a great walkthrough of how you can use the Solution Generator. You can also point the Solution Generator at WSS sites you may already have created (in effect reverse-engineering them).

This could be handy if you have already customized a site using SharePoint Designer or the browser and you need to place those changes in source control.

WSPBuilder

Similar to the SharePoint Solution Generator is WSPBuilder. Developed by Carsten Keutmann, this tool allows you to easily create solutions files. As he puts it: "The WSPbuilder is a console application that creates SharePoint Solutions files based on a folder structure. WSPBuilder will automatically traverse a "12" folder structure and creates a SharePoint solution manifest.xml and the wsp file based on the files it finds. Therefore you do not need the knowledge of how to create a solution manifest.xml and wsp file any more." WSPBuilder is available on the CodePlex site (http://www.codeplex.com/wspbuilder). This tool is useful after you have created a SharePoint Feature, so it won't eliminate that step. Having used it, you can add to your source code repository your Feature folder and the Solution file generated by this tool.

echo for SharePoint 2007

echoTechnology says echo is "a tool for...managing the software life cycle in development, testing, and production...It helps managing Features, Content Types, and workflows, all of which are easy to deploy but difficult to change." I've blogged about this and how it is intended to be used at Planet MOSS here and here, and you can check out their website at http://www.echotechnology.com. echoTechnology have also released a free utility called SharePoint Spy, which allows you to investigate the exact properties and values of SharePoint lists, items, sites, and site collections.

Other Tools and Resources

CodePlex is the likely destination for many other development and SDLC tools and keeps growing as the community strengthens around SharePoint. One thing to be aware of is that many of these projects are in alpha or beta states, and are likely to lack much if any support, so use at your own risk!

Finally, here are some links to other useful resources:

• Windows SharePoint Services 3.0 SDK
• Microsoft Office SharePoint Server 2007 SDK
• Microsoft Developer Portal
• SharePoint newsgroups contain lots of guidance about development issues.
• Microsoft is releasing some great resources for kick-starting SharePoint development.

Good luck!

About the Author

Nick Kellett is a former alumni of the SetFocus Master’s Program Java Track, with over a decade of Java and .NET development experience in New York, London, Ottawa, and Sydney. He has been working with SharePoint since the Office 12 TAP program and is currently contracting in Australia. Nick has delivered over a dozen successful SharePoint 2007 projects for government and private-sector clients. Technical deliverables for these projects include managing low-bandwidth content replication, creating Business Data Catalogue schemas, architecting site and farm topologies, designing master pages, and developing workflow processes.

• Nick's Blog:  Planet Moss, at http://planetmoss.blogspot.com
• Nick's LinkedIn profile at http://www.linkedin.com/in/nicholaskellett