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.
8 Responses
Interesting article. I see that you mentioned NUnit. As an organization we have a 100% code coverage (Unit Test) policy with a continuous integration server. This works very well with our custom development projects. But unit testing SharePoint and continuous integration seems to be a pain. Have you at any point been able to completely unit test your sharepoint app? If you have can you put out an article outlining how you did it with continuous integration.
@John: Yes, we did some continuous integration with SharePoint, but you are 100% correct it was a pain. I will post an additional article on how you can some of that and what are the limitations.
Great post and idea Toni. I have a question about our dev environment. Could I use my existing test environment hardware and resources to service my dev environment.
I would still build SharePoint FEW VMs on the developer’s workstations, but point them to the SQL server, ISA server, Active Directory, etc.. in our test environment.
My questions are around central admin and the application server. Would those have to be installed in the test domain on a server would could those live on the developer’s SharePoint FEW VMs?
Well I would go for Dev Workstations. It would be much easier to configure and developers are much more flexible (to restart and similar).
Hi. You wrote “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.” Did you ever publish the specifics on the dev env? Thanks.
@Jake: I do not have exact specs at hand but two years ago we bought some entry level HP servers and we are satisfied to the date with these. Today you should probably go for some QuadCore, 16 GB RAM entry level HP server or workstation and you will be OK. You should definitely go for x64 Windows 2008 R2 Hyper-V for your VMs.
Why should we use the Server OS as the host OS.Can’t we just use Vista, or now WIndows 7. These are for the Developers Box only.
What are your thoughts on this? Is is a good practice. Also from a development stand point can we just use WSS if we have to create webparts and features.
@Sunjay: Well client OS like Vista or Windows 7 do not allow installation of server based VM technology like Hyper-V, VMWare Server or similar. To achieve best performance I would advise Windows 2008 R2 Hyper-V as you host OS. I am not HW/VM specialist so I cannot provide all the details but this is the best combination we found for SharePoint development.