Paul Liebrand’s Weblog

Welcome to my blog mainly about SharePoint

SharePoint – A different development philosophy

One question that I hear time and time again is “How do I move our work in SharePoint from development to testing to production?”

Traditionally when it comes to development, most organizations have a development, testing, and production environment. These environments are normally used in a standard development lifecycle (“SDL”); developer codes, it gets implemented into the test environment for the testers and ultimately lands up being implemented into production. Companies attempt to apply their SDL concepts with their SharePoint deployments. This misconception often stems from the fact that creating new pages, content, or even workflow using SharePoint or SharePoint Designer is associated with “custom development”. However, In my opinion the SDL cannot completely be applied to SharePoint. In this post, I’ll attempt to explain where the development lifecycle can be used and where it should not be used.

In order to completely understand where I am coming from on this you will need to think about SharePoint in a different way. SharePoint at is core should be treated like any other Office application for example Microsoft Word, or Microsoft Excel. Let’s take a look at a users experience with using Microsoft Word compared to SharePoint as an example:

  Microsoft Word SharePoint
Voice Enabled through the creation of Word documents. Enabled through the creation of pages, content, and web parts.
Look and Feel Enabled through the usage of document styles. Enabled through the ability to move content around on the page, site themes, or using SharePoint Designer.
Sharing Enabled through the ability to store the document on the network, or send via e-mail. Enabled through the ability to invite other users to participate on your site.
Advanced Enabled through the usage of document templates and macro’s Enabled through the usage of SharePoint Designer.

It is important to remember that at the core, SharePoint is just creating and storing content. Whether you are uploading documents, or adding contacts to a list, it is just user created content. Just think that when a user wanted to create a new word document, they would have to first develop it in a development environment, and then copy it to a testing environment for verification, and then ultimately copy it to its final resting place in production. This would just be a very inefficient and impractical way of working.

The same applies to SharePoint. If a user wants to create a new page to store content it should be done directly in the production SharePoint environment. Whether they are using the built in tools that the direct SharePoint user interface offers, or using SharePoint Designer to accomplish more advanced documents, it should not matter.

Until you accept this fact, you will be sorely disappointed in the ability to move “content” from development to test to production. Understand that I am not saying it cannot be done but you need to question whether it should. There are products on the market now that support the ability to move content from one environment to another, these are generally used when you are publishing content for an Intranet. And there are many posts on how to hack up a SharePoint Designer workflow created in one environment and move it to another.

So when is a good time to use the SDL methodology when it comes to SharePoint? Well, remember that SharePoint is a development platform, so anytime a developer is able to produce code using Visual Studio is when you would follow the SDL. For example, if the developer builds a custom work flow assembly, a custom site definition, or an event handler. This is code that should be implemented and tested in each environment to insure it is functioning properly. More importantly, developers should be taking full advantage of the solution framework that is now baked into the WSS 3.0/MOSS 2007 architecture to make the implementation in each environment cleaner and more consistent.

At my company we basically use our development environments to test concepts around solving a specific business problem. We then either assist the business user with implementing that into their site or just perform the work ourselves once giving permission to the site by the user. On occasions we will perform full refreshes on portions of the data into our other environments if there is something specific we need to test/troubleshoot.

If you are in the process of implement SharePoint in your environment, you may want to start having discussions around how you will be handling user generated content versus developer generated content.

I hope this post has been informative, if not, let me know and I’ll try to clarify. I assure you, this will not be the last time this topic is discussed.

Note that the information in this post is based on my personal opinion and experience.


June 20, 2008 - Posted by | SharePoint |


  1. Hi,
    Its a really good post.
    I am working in the company which has the hosted MOSS. We only have one dedicated server. I am the sole developer but there are 10 other persons who can upload the documents in the portal, now how i suppose to implement the test env. ? and prod?

    Please help.

    Comment by don | September 25, 2008 | Reply

  2. Don,

    There is absolutely nothing wrong with building out a development environment (if it is just you, this can easily be done via Virtual PC). The environment should be used to develop and test custom solutions. Once you satisfied everything works, you can then package that stuff up into a WSP and deploy it to your production environment for your users to take advantage of.

    Hopefully this helps.

    Comment by liebrand | September 25, 2008 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: