Building a SharePoint 2007/2010 development environment – Part I: Introduction and Objectives

As I’ve alluded to a few times in this blog, over the last few months I’ve led the consultancy and system design for a SharePoint 2007/2010 development environment built on Hyper-V in Windows Server 2008 R2. This series of six posts will reveal the key decisions and will consolidate recommendations from a broad range of research and guidance. This first post offers a technology-agnostic introduction to the problem, pros and cons of alternative approaches and what we hoped to achieve with the new approach. The design decisions will be covered in more detail in the second post, followed by a deeper look at detailed build guidance.

Historical development approaches

We have used a variety of development approaches in the past, which have all had limitations and were often an obstacle to productivity. They included:

Shared development farms

Shared farms are appealing at face value because they put development resource hunger on beefier infrastructure. However, there are considerable drawbacks to this approach, including:

The infrastructure burden of these environments is immense

Due to limited physical resources, these servers housed multiple projects in a single farm, leading to hive pollution and a less reliable/predictable development environment

When multiple developers would use the same farm, this would amplify resource contention on already strained servers and it made managing application-level change much more difficult

Local development

Developing SharePoint directly on a Windows Server 2008 laptop introduced a need for frequent laptop rebuilds, as the SharePoint customisations for one project rarely carry over to another and the hive gets polluted. This adds a hefty support burden and frequent down-time for developers.

Virtualised development using Virtual PC

Virtual PC is a friendly technology for SharePoint developers to use, as it does not over-complicate virtualisation, but the management functionality (such as snapshots and snapshot export) is inflexible and performance is poor when compared to a Type-1 hypervisor.

Third-party virtualisation technologies

Most third-party technologies have associated license costs for businesses and many do not support virtualisation of 64-bit guest operating systems. This is problematic because:

Windows Server 2008 R2 is only available in 64-bit

SharePoint 2010 is only available in 64-bit

Additionally, many developers have strong preferences for third-party virtualisation vendors and if this is not controlled/standardised it can introduce incompatibility issues.

Why none of these approaches were satisfactory

In short, these environments did not offer good enough performance or management flexibility and we needed a standardised approach for business continuity. We also needed a technology that would support 64-bit systems.

SharePoint development complications

SharePoint development in teams has always been tricky, as SharePoint virtual machines cannot be easily cloned and renamed. This means that SharePoint environments require:

Scripted installation, which is great for standard builds, but not terribly easy to reconfigure for project-specific requirements, or…

Manual installation, which is time-consuming and not always aligned with a developer’s skill set, or…

Shared environments, which suffer from the drawbacks outlined above, or…

Network isolation of the cloned machine so that that nothing on the network will ever be aware that there are clones

These are some of the biggest issues that need to be confronted when designing a SharePoint development environment. This list is by no means exhaustive; in the final post in this series I’ll be reviewing some of the issues that we’ve encountered during a pilot and subsequent roll-out to all of our developers, consultants and architects.

Distilled objectives

After a thorough review of development approaches, difficulties and available technologies, a Windows Server 2008 R2 (RC) with Hyper-V pilot was announced, soliciting senior developer/architect participation, stating the following aims:

Improve performance over Virtual PC by adoption of a new core virtualisation technology

All available performance guidance for hardware, Windows, IIS, SQL and SharePoint would be considered for inclusion in the build

Hyper-V R2 was adopted early for the pilot (at Release Candidate) to take advantage of further performance gains in the new version

Project cost effectiveness would be improved by:

Removing development tools and SharePoint from the host machine, reducing the amount of reconfiguration on laptop rebuild and reducing rebuild requests

Providing a suite of pre-configured virtual environments, reducing setup time at project commencement

Making project-configured environments reusable within teams throughout the life of the project with Hyper-V’s snapshot technology

Eliminating the infrastructure burden of shared development farms and re-provisioning those resources to better purpose

Improve the testing process by introducing snapshots

In conjunction with the pilot we upgraded physical disk speed and capacity from 160GB 5400 RPM drives to 300GB 7200 RPM, as Hyper-V snapshots chew up lots of space, and the added spindle speed is critical to improving performance.

Defining these objectives, limiting the duration of the pilot and testing the new approach were critical to gaining management support for the project. In advance of pilot deployment I trained all pilot participants on Hyper-V and introduced our approach to networking and source code storage, which would not be obvious otherwise.

In the next section I will cover the design decisions that were reached through consultancy with the business, pilot findings and research.