SharePoint 2010: Establish the proper environment
The manner in which you set up your development and testing environments and processes can greatly impact your applications.
Steve Wright and Corey Erkes
Adapted from “Pro SharePoint 2010 Governance” (Apress, 2012)
Throughout the course of any large development project, you’ll need to manage different types of information. It’s preferable to have a central repository for this information that integrates with the other tools used by the development team.
There are several products to help your development teams collaborate and communicate, and Microsoft Visual Studio Team Foundation Server (TFS) has advantages when used for SharePoint development. It’s tightly integrated with both Visual Studio and SharePoint. If your organization doesn’t already have such a tool and will be developing applications primarily for the Microsoft Windows environment, you should consider TFS.
Regardless of the product and method you choose, there are some features that such a platform should have, including:
- Source Code Control: This maintains a record of every change to every source file in the solution. SharePoint library versioning is not appropriate for this purpose. A true source control system supports many features beyond tracking a single sequence of file changes.
- Requirement Management: This traces each bug, source file and work item back to the requirements to which it’s related.
- Work Item Tracking: This logs the bug reports, help desk tickets, feature requests, releases and tasks associated with the project.
- Build Automation: This compiles the source files into deployable solution files.
- Test Management: This records automated and manual test cases, automates regression and unit testing, manages deployment to test server farms, and performs load testing.
Not all team development platforms will support all of these features. However, source code control is one function that is absolutely necessary to maintain a stable application base. The other functions may be more or less important to a particular organization. It may also be acceptable to use separate, non-integrated tools for those functions.
Developer environments
One of the more challenging aspects of SharePoint development is establishing a productive development environment. This refers to the area where an individual developer can work to create and debug his assigned components or updates. SharePoint is a server-side technology, so components designed to run on a SharePoint server generally have to be developed on one as well.
One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well. Developers need complete control over the server to effectively debug issues. Isolating developers from one another is the best way to keep everyone productive.
Another misconception is that you can develop on a client system running Visual Studio and debug on a remote server running SharePoint. While you can debug a SharePoint solution running on another server, you must still have SharePoint installed on the system compiling SharePoint server-side code. The libraries the server-side code uses are available only on a SharePoint server. You can’t have them installed separately on a client computer to allow code to be compiled. If you’re developing client applications using only the new Client Object Models (Client OMs) introduced with SharePoint 2010, you can compile them on a system that doesn’t have SharePoint installed.
A minimal SharePoint development environment should include the following:
- A 64-bit Windows OS compatible with SharePoint 2010 (Windows 2008, Windows Vista SP1 or Windows 7)
- Visual Studio 2010
- SQL Server Express Edition
- SharePoint Foundation or Server components as needed
The following tools are often useful and you should include these whenever possible:
- Microsoft Office applications
- SQL Server Developer Edition
- Microsoft Visio
- InfoPath Designer
- SharePoint Designer (free download)
You also have several options to consider regarding where you install these tools. The first and simplest option is to load all of the tools and SharePoint directly on the developer’s computer. This requires a 64-bit OS compatible with SharePoint. This configuration is easy to use because all of the necessary tools are readily available.
Unfortunately, this configuration is limited by the power of the desktop computer, the storage of the hard drive, and the fact that you can only use one SharePoint configuration. A developer who frequently moves between projects might find this type of configuration difficult to manage.
Development environment options
The next option is to use a desktop virtualization product such as Oracle VirtualBox or VMware Workstation. Again, you must be certain that whichever virtualization tool you use supports a 64-bit guest OS. This configuration has many of the same limitations as directly installing the environment on the desktop. Typically, performance isn’t very good and you’ll need large disk files to support desktop virtualization.
The advantage to this type of environment is that it lets you host multiple SharePoint configurations in separate virtual machines (VMs) on the same desktop. Typically, memory and performance requirements don’t let you run more than one VM at a time, however.
You can also create a virtual hard drive (VHD) file and run it directly on the system without going through a desktop virtualization product. This is similar to the old “dual-boot” setup for a system. Instead of using a separate partition for the second OS, you’d use a VHD file within the existing OS file system. This configuration has the advantage of using all of the system’s hardware without requiring a second OS running to host the development server.
The only disadvantage is that any applications loaded on the desktop’s client OS aren’t available while running the development environment. This is quickly becoming the most popular configuration for SharePoint developers because it provides the flexibility of desktop virtualization without incurring the performance costs. For more information on running multiple OSes using the new Windows 7 boot configuration, see Keith Combs’ blog post, “Dual Boot from VHD Using Windows 7 and Windows Server 2008 R2.”
The final configuration uses server virtualization. This could be Microsoft Hyper-V, VMWare or any other server virtualization product. This is an excellent option for an enterprise with a good virtualization infrastructure. Provisioned a VM on a VM host server and use that server to house the entire development environment.
Using a Remote Desktop Protocol (RDP) client, your developer has access to a complete environment without making any changes or installations on his local environment. The only disadvantage with this configuration is that you must be able to connect to the VM server in order to perform development tasks. You can’t “take it with you.”
Testing environments
Once development is complete, you’ll have to put the application through a rigorous, well-defined testing regimen. This requires that you load it into one or more non-production environments prior to production deployment. These environments go by many names including integration, test, stage, user acceptance testing (UAT), pre-production and so on.
You could use an integration farm to test all of the compiled components in an environment that doesn’t contain any development tools. The presence of Visual Studio or other development tools on a system can sometimes mask errors that only occur when those tools aren’t available.
Once the release is tested, deliver it to the quality assurance group, or whichever department is responsible for UAT. Then that testing group will load the release to the pre-production farm. This farm should be as similar to the production farm as possible to help the testing group assess the release’s production readiness.
For example, if the production farm has multiple front-end Web servers, so, too, should the pre-production farm. Virtual servers are often substituted for physical servers to make the testing environments more cost effective. Once UAT is complete, you can deploy the application to the final production server farm.
When testing a new release, it’s important to use content as similar to the content in production as possible. For example, if a user has customized some item in a site in the production farm that interferes with a change made to the application, you might not notice if the change is only tested against “phony” test data. An excellent source of realistic content data for testing is the production server farm. You can easily back up and restore the production content databases in the test environments in most cases.
Another common configuration for testing and deploying SharePoint applications is to use a staging server farm. With this technique, there are two complete server farms running at all times. Your users use one and the other stands by to receive the new release. Once the release is deployed to the staging farm, the network is reconfigured to route incoming traffic to the staging farm. Thus, the staging servers become production and the production servers switch to staging.
This is a useful technique for public-facing sites on which you can’t permit downtime. The time required to swap out the server farms is only as long as it takes to reroute the network traffic. Obviously, it’s vital that all production content updates are moved to the staging farm prior to deploying the new release. To prevent updates after the content starts being copied, SharePoint lets you temporarily lock content databases.
When you use this technique, the staging environment can also serve as a hot standby for the production farm. If production suffers a catastrophic failure, you can quickly bring up the staging server to restore service. If this is part of your disaster recovery plan, you should regularly copy production content to the staging farm, even when you aren’t deploying new releases. It may also be useful to have the staging and production farms hosted in separate physical locations to provide location redundancy. Any of these techniques and configurations can help you develop a SharePoint development environment that best suits your needs and resources.
.jpg "Steve Wright")
Steve Wright is a senior manager in business intelligence management (BIM) for Sogeti USA LLC in Omaha, Neb. Over the last 20-plus years, Wright has worked on air traffic control, financial, insurance, and a multitude of other types of systems. He has authored and performed technical reviews for many previous titles covering Microsoft products including Windows, SharePoint, SQL Server and BizTalk.
.jpg "Corey Erkes")
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He’s also one of the founding members of the Omaha SharePoint Users Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.