21 Dec, 2008
Team-Based Development in Microsoft Office SharePoint Server 2007 – Part 2 – Building a development lab
Posted by: Toni Frankola In: SharePoint 
In previous post of the series, I blogged about classic mistakes and best practices for SharePoint development. In this post I am going to focus on the following best practice:
The best practice approach – Development lab
In last few years I managed a number of SharePoint based projects and most mistakes I mentioned in my last post I experienced working on these projects. In last few weeks, we analyzed all the mistakes and here is how you can avoid these.
The following figure (click to expand) outlines the schema of the lab we built internally.
Lab components are:
1. Developer’s Workstations LAN
Each developer has a workstation with the following characteristics: HP brand-name, 64-bit, 4GB RAM, two hard drives, Windows 2003 host operating system.
On his own workstation a developer runs virtual machine(s) pre-installed with SharePoint, Visual Studio and other tools. All the work he needs to do is being done on the virtual machine. Host machine is used to host virtual machines 
, emailing with Outlook and other similar stuff.
We are using Virtual PC and Virtual Server as virtualization technology on workstations.
Usually a developer has only one VM running. For each project he is working on, there is a different SharePoint Site Collection.
You will achieve best results if you create a developer VM from scratch. I will described how to do that in next post of this series.
2. Core Services LAN
Core services allow SharePoint developers to work smoothly and reduce resource consummation on workstations. Each server on the figure above is also a Virtual Machine, but these machines are hosted on production servers. We are using Virtual Sever and Hyper-V as virtualization technology. The core services are:
- SQL – this is central SQL database server, for all SharePoint VMs in the entire lab network. We have decided to add external SQL in order to lower resource consummation on a developer workstation and other SharePoint – Project VMs.
Most SharePoints in our network are configured as simple farm: WFE + SQL backend - Mail - this is server with SMTP and Exchange installed. All SharePoints VM are using this server to rely email messages
- DC – this Domain Controller for this lab domain.
- VSTS – we are using Visual Studio Team System 2008 to store our code, and organize work items on each project. (in real world this server is in another domain)
- ISA – It serves as Firewall that divides our internal network from DMZ
3. SharePoint – Project VMs (DMZ)
The servers on this LAN are SharePoint VMs. Each project we are working on has it’s own VM. Each machine is available online (web interface only), allowing customers to preview solutions we are developing for them. This is a crucial thing on a SharePoint project. Since we are using iterative development approach it is important that customers can provide feedback as early as possible.
Project VMs are basically integration machines. Each developer deploys project code to this machine. Once deployed it is being tested in a simulation of customer’s production environment. For some projects we are using continuous integration tools like CruiseControl and NUnit, but sometimes, due to complex environments, some items can only be delopyed and tested manually.
In next post of the series I am going to explain how you can build your VMs.
