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.
2 thoughts on “Building a SharePoint 2007/2010 development environment – Part I: Introduction and Objectives”