SharePoint Use Cases

I already blogged about setting up a SharePoint team, and I am going to explain the technical side of that in this post.

Here are the classic mistakes and best practices on how to setup development environment for a SharePoint team.

Environment 101

Mistake – Installing SharePoint on a developer workstation

It is nice to have all the tools you need installed on your workstation / laptop. This is a wrong approach for SharePoint projects. SharePoint is a very complex software product and it will probably mess-up something else on your computer. So you will end up reinstalling it, every few months.

SharePoint also requires a Windows server to run, which you can install on workstation, but you will not be able to run some client applications (e.g. Adobe Creative Suite).

The best practice – SharePoint in a Virtual Machine

The best practice for setting up development environment is to use a virtual machine. VMs are easy to manage and host operating system is completely isolated. You can tear apart VM, but host machine will not be affected. The benefit: You can have a different machine for each client/project you are working on.

Here are some useful links on this topic:

• How to Create a MOSS 2007 VPC Image: The Whole 9 Yards
• Scott Hanselman’s VM Performance Checklist – Before you Complain that your Virtual Machine is Slow

Virtual Machines 101

There are various options for using Virtual Machines and here are some mistakes and best practices when it comes to SharePoint development:

Mistake – Using a Virtual Machine provided by Microsoft

You can download a preinstalled VM with SharePoint and everything you need from Microsoft web site. These machines are great because they included all the tools and services you need to do presentations and developing for SharePoint. However you will encounter the following two problems when using them:

• VM is set to expire in few months, and sometimes it is very hard (in some cases impossible) to prolong that
• If two or more people are using this machine on the same network this will cause you a lot of problems. Renaming a server with SharePoint and Domain Controller installed is a nightmare, and you cannot have two machines with the same name on your network.
  So, sooner or later you will abandon this approach.

Please note: If you only need to do a simple pilot, or a demo you should stick to this VM. It is great and rapid tool for simple scenarios.

Mistake -Single Virtual Machine approach

The next approach you will probably try is having one virtual machine per project, and use it as integration (sometimes even development) server. Each developer uses this machine for debugging, deployment and integration.

This is a mistake, reasons:

• Deploying SharePoint stuff often requires you to restart IIS or recycle pool. If you have two or more developers working on this machine this might be a problem, because all these restarts will decrease productivity of a developer.
• No matter how much RAM you allocate for this machines, you want be able to allocate enough.
  It is always hard to allocate enough if two or more developers are using Visual Studio debugger on the server

The best practice approach – Development lab

In next post I am going to describe how and why you should build a testing lab for your team.

Related articles:

• Bulding a SharePoint team
• Team-Based Development in Microsoft Office SharePoint Server 2007 – Part 2 – Building a development lab