Tuesday, 27 February 2007

Series : how to create common MOSS site artifacts as features

Having been through the process of creating a MOSS site entirely through Features, it struck me how non-intuitive some of the associated tasks are. Many SharePoint developers who are working in this way will agree that something that takes 30 seconds in the UI can take several hours in Visual Studio. Over the next few articles, I'll note some of the issues I came across in this process, and also the solution I used for each.

But first, let's be clear on why developing SharePoint Features is the way to go for MOSS development. The main reasons as I see them are:-

  • ability to deploy updates through dev/QA/staging/production etc. in a repeatable manner (i.e. without recreating things manually through the UI - since this wouldn't scale well across many environments)
  • ability to deploy updates to all the web-front-end machines in the farm in one go (when the Feature is wrapped in a Solution - more on this later). Again, this avoids config management issues due to human error.
  • ability to properly source control the artifacts which comprise your MOSS site/application
  • to have a good foundation for Continuous Integration. Many shops would want to include their MOSS development in their automated build routines, and having the functionality created/deployed as Features facilitates this.
  • option of doing basic config management through the UI. Whilst most SharePoint devs/administrators would be comfortable writing STSADM deployment scripts, it's useful that less technical people can deploy/rollback changes if required. Obviously, most deployments would want to consider appropriate permissions for this ;-)
  • ability to have custom functionality automatically be included in the sites created by end users.

Andrew Connell's article on the benefits of deploying in this way is definitely worthwhile reading.

The next articles in my series will be:-

So long for now..