General Ramblings on Development Environments ...

This is mainly a post in response to lots of posts I've seen on the MSDN forums asking the same question. "What should I use for my development environment"?
So I figured I would share some of the experience that I've had in this area.

The key word here is virtualisation, virtualisation, virtualisation! If you are serious about SharePoint Development then you simply HAVE to virtualise your environment. The reason for this is because of several key issues that SharePoint Development throws up:

---

1. The Object Model Issue - Windows Server IS required
This is a fundamental issue with any development work that utilises the SharePoint Object Model (a.k.a. The SharePoint API). It will ONLY run on the same physical machine that SharePoint has been installed on, and you can ONLY access content and sites that are running on that box.
Now this creates a number of initial stumbling blocks for developers. Most developers out there would be (and really should be) using XP or Vista for their workstation (which is quite right .. XP and Vista are the two latest Workstation Operating Systems .. you certainly shouldn't be running Server as your host OS). But, you cannot execute any SharePoint code on either XP or Vista, because you need SharePoint which can only be installed on a Server OS.

Now, you could go down the root of setting up remote debugging and basically writing and compiling your code on the workstation, deploying to the server and debugging from there by attaching to the processes.
However this means that you not only have to spend time setting up remote debugging but this can also lead to security issues if your Workstation and SharePoint servers run in different domains.

Just as a side note, our Network Infrastructure Manager would never let us do development work on the live company domain. Mainly because we would be creating dozens of test accounts and creating dozens of web servers and potentially "vulnerable" working environments. It is much safer, easier and secure to setup a separate "development domain" .. you know that you can do pretty much anything you like without annoying the IT Support department where you work ;)

2. The "12" folder.
This is a physical folder on the hard disk of the SharePoint Server and it contains the XML manifest files for all of your Features, Site Definitions (onet.xml) list definitions (schema.xml), your user controls (_controltemplates), your Site Pages (_layouts) and any other physical files and resources that you want to be globally available. The main issue here is that there is only one physical folder on the server. If you modify any of the files here then you will be modifying them for ALL web applications and ALL site collections that are running on that machine.
So if you are expecting to be doing any development which changes these files (which you most likely will if you are doing any more than just selecting options through Site Settings) then you really need to have multiple server environments to develop in.
Even if you are only working on a single project, you will still need several environments {Development | Testing | Staging | Production}

3. Global Assembly Cache
This is pretty much the same as point #2. There is only one Global Assembly Cache, and if you are creating, installing and testing dozens of different web parts (for different projects) then you are going to start getting a messy GAC. Also, any GAC references will probably require web.config changes, and this might also get messy if you are trying to write software for different environments.

4. Developing in a Team .. and debugging processes
For any software development company, this is a big one. No two users can debug the same process at the same time.
Now with standard ASP.Net development this was never a problem. Visual Studio installed it's own web server and you could run, debug and test your code on your workstation ... but with SharePoint this is not possible. You need a Server OS to run SharePoint code, and you won't be (or shouldn't be) running Server on your workstation.

So this instantly raises problems for debugging code. Ideally each developer should have their own SharePoint environment so that they can happily attach and debug processes without interfering with anyone else.

(we've had teams of 2 people where this has caused problems ... for larger teams it just gets worse!)

---

So .. in short, it is far easier to have multiple environments, each one with their own clean installs of WSS 3.0 / MOSS 2007 and their own clean GAC and filing systems.
You should have one environment for each Developer.
You should also have a clean environment for your Test | Staging | Production installs too!

So what about setting this up? Well Virtual Server (or the workstation version, Virtual PC) holds the answers. You can create "virtual machines" that can be copied from machine to machine and run from within virtually any host OS.

Now this is the bit that really has to be done right from the start.
Create a "base build" Virtual Machine (for example, with Windows Server 2003, Visual Studio 2005 / 2008 (for debugging)).
Do NOT attach the machine to a domain (leave it as a Workgroup .. the reason for this will become apparent later).
Install SharePoint onto that machine as a "Stand Along Install" (so that SQL Server and all the trappings go with it), along with the Visual Studio extensions for SharePoint and Workflow.

That should give you your base image
(for those wondering, our own base images are roughly 6GB in size when first created. Obviously the more work you do on them, and the more software you install, the bigger they get).

The "base image" should basically consist of a VHD (virtual hard disk) and the VMC (Virtual Machine Configuration) and it's the VHD that we want to use here, there and everywhere.

Basically .. Copy and Paste this file and you can use it to create multiple machines.
This is the good bit .. you don't need to spend 2-3 hours installing and configuring a new server every time you want a new build. Just take a copy of the VHD and off you go (so .. what .. 10-15 minutes?)

Each developer can take a copy onto their local workstation. They can use that VHD as their SharePoint development environment. As it is running locally they should have access to their local disk drives from the virtual machine, so they can copy files back and forth from their workstation to the virtual "server" environment.
If you reach the end of a project, or you've been playing about and messed up the machine you are working on, just take a new VHD copy and start again! it's that simple! And each time you start over you can guarantee that you are working on a clean, vanilla install of MOSS.

You can even run your Test / Staging environments in the same way. Just run multiple Virtual Machine environments using Virtual Server. If you are running several projects at the same time, create copies of the VHD for each project (you will only realistically be limited by disk space and memory!)

Now for the hardware
The developer workstations are going to need some pretty hefty kit if they are going to run multiple virtualised machines. These Virtual Machines are running Windows Server 2003, SQL Server 2005, SharePoint (either WSS 3.0 or MOSS 2007), Visual Studio, and problem some other tools along the way.
So they will need at least 1GB of RAM to runn smoothly.

So for the Dev Workstation, my recommendation:
Dual or Quad Core CPU (if you want to have enough resources to run multiple Virtual Machines as well as your host OS, then you need this)
minimum 2GB of RAM (and preferably 4GB .. with 2GB "speedboost" stick if you are running Vista!) Basically the more the better ... each VM will chew up 1GB each .. once you run 2-3 machines you run out of RAM real quick (and your Host OS is going to need around 1-2GB just for itself!)
Large (250GB+) Hard Disk. This is for the VHD storage. Once you start installing, running and playing about with the VHDs it is not uncommon for them to be around 10-15GB in size each. If you are running 4 projects, and take a couple of backups of each VHD then thats over 150GB of disk space gone already. Besides .. hard disks are dead cheap so why not go for a HUUUGE one :)

Anyways ... got to dash off to that conference now so thats all for today! Tune in next time and I will be talking more about development environments, this time the applications used (e.g. SPD, VSS, VS2005, VS2008 .. etc)