Summit 7 Team Blogs

SharePoint 2010 Dev. Environment – Part 2


This is a continuation of an earlier post relating to the architecture and configuration of a SharePoint 2010 development environment which can be found here. In the original discussion, I started detailing out the concepts and requirements for single and multiple server development environments as shown in the following diagram:


As a quick review, the single and multiple server development environments each have their own unique purpose. Single server environments are ideal when there is a need to develop a quick proof of concept or to develop out a simple solution that does not require access to advanced functionality such as multiple service applications or access to full SQL Server instances. Multiple server development farms are ideal for more advanced situations primarily because they allow for the distribution of functionality across servers, which leads a more responsive environment. Having a single server environment handle the resource intensive demands of a full SQL Server instance, a SharePoint Web Front End, SP Search indexes, and multiple SP Service Applications all within one machine, could bring development times to a crawl because these applications would be competing for the same resources.

Ultimately, the decision of which development environment to begin with is a personal decision and should be chosen based on the requirements gathering and solution discovery phases of the program.

Multi-Server IT Pro Farm

Outside of the development of a complex custom solution with the use of tools such as Visual Studio, there can be times when the development of a solution aligns more with that of an IT Pro task. It seems more and more common that I will be involved in the development of a solution that is along the lines of an architectural solution as opposed to a pure custom coded solution. It is because of this that I have a specific need to have an IT Pro based environment.

What differentiates my IT Pro farm from my Development farm? Basically, it’s what’s not there that makes it necessary. Within my development specific environments, there are additional tools that are installed such as Visual Studio 2010, FxCop, CKS Dev. Tools, etc. The IT Pro environment is void of all these extra tools. Perhaps, the only tooling application that should remain in this environment would be the SQL Server management tools, not to provide access to the SP content databases but more to provide the ability to create databases that could be used with the Business Connectivity Servers application. Additionally, the installation of applications like Visual Studio 2010 include not only the development IDE but also a number of supporting framework packages, SDKs, and other additional software that wouldn’t normally be available within a SP Production environment.

By removing as many of these tools as technically feasible, the IT Pro environment provides a solid foundation to develop solutions by utilizing out of the box functionality and SharePoint Designer 2010.

Multi-Server Integration/Quality Assurance Farm

Much like the Multi-Server IT Pro environment, the Integration/Quality Assurance Farm should be void of any supporting development applications or SDKs that would not normally be found within a production SharePoint environment. Now, it’s understood that actual production environments can come in various shapes and sizes. Although there are many variations to the architecture that are possible, as a solution developer, the accessibility of SharePoint’s multiple capabilities will, in general, operate in the two server IT Pro farm similar to how they would within a fully load balanced production implementation.

This clean and sterile environment will allow for the testing of solutions without the additional configuration settings that could have been applied during development. Though I’m sure every developer takes extra precautions to ensure that all configuration settings for a solution are well documented in order to replicate the deployment without issue, there will inevitably be the case where this process fails and it is the role of this development environment to expose these flaws.

As mentioned before, the Integration and QA environment can, and most likely will, be hosted within a set of virtual machines. That said, this environment should be hosted in a central location which could be available to anyone within the development team, depending on the size of the team. This would serve two purposes. First, a centrally hosted integration environment will allow for better integration with other efforts that might be going on simultaneously. By following the previous deployment process of developing your solutions within the multi server development or IT Pro farms, the solutions deployed here should be relatively stable and will provide the first opportunity for developers to have their components interact with other solutions.

Second, having a centrally hosted integration environment allows for tighter control over the configuration. This environment should have a set of administrators designated to this farm and to manage access permissions and overall configuration. With this, you can ensure that inappropriate areas of your system, such as the web.config file, are not being modified without the proper procedures. Additionally, in many workspaces, it would be common to have the build out and configuration of the Integration and QA farm in a scripted format so that the tear down and rebuild of the environment can be readily repeated in the event that a solution or configuration breaks the system.


In the end, the architecture and configuration of a developer’s environment is of personal preference. Hopefully, I’ve been able to shed a little light into how I operate on a day to day basis and I welcome hearing about the advantages of your environment.



This entry is cross-posted at