What environments SharePoint developers utilize as a part of their solution delivery life-cycle is crucial. The model outlined below is meant to empower the developer to the greatest extent possible, while also safeguarding SharePoint. Every month, more enterprises begin using this approach.

The Development Environment

The Development environment should have only one server, even if your production SharePoint farm has multiple servers. The reason for this is simple: Visual Studio does not play nice when debugging a multiple-server farm. If you want to attach to the ASP worker process, or any other process used by SharePoint and your code, you should avoid having multiple servers. Additionally, when you have Visual Studio set up with the SharePoint Community Kit (a must-have for SharePoint development, IMO) you can only automatically deploy to a single-server farm. Automatic deployment saves an enormous amount of time over the course of development. Each developer should have their own development virtual server. This will give them the ability to create or restore development environments on a whim, which greatly eases the development process and can speed up delivery.

Testing

Next, you should have a test environment. This is the shared environment for a team or project where you assure that the code works in a near-production environment. This environment should roughly match the farm you have in production. This environment doesn't have to be on the same patch level as production, nor does it need to have all of the solutions and customizations. It should not, however, be a single-server farm. SharePoint solutions should be tested for multiple-server farms, even if your production environment is currently a single-server farm. The problem with having a single-server farm as a test environment is that you may run into issues down the road when you scale out production by adding additional servers. You want to assure that the solution you are developing is scalable and will grow with your SharePoint farm. Test environments can be shared across multiple projects or created for each project.

Staging

The third environment is for staging. This is the environment that should match production in as many ways as possible. It's not for testing out code, but is used as a final validation point for completed solutions. Its function is to assure that deploying new code to production will not cause problems to existing functionality. It's also meant to assure that the deployment steps for the solution will work smoothly in production. This environment is shared across all SharePoint development projects and development teams. It's also utilized by the architecture/infrastructure team to validate patches and hot fixes before they are pushed to Production. Therefore, this environment should have strict change management processes. This environment should be periodically recreated from production.

Production

Finally, we have production. For custom-coded solutions, best practices dictate that no development should ever occur in production. This is the environment where users work. It is where your business operates and therefore it is business critical. Any downtime here can result in lost revenue and missed opportunities. These environments constitute the components of a well-oiled SharePoint implementation. With the proper change management, this model gives the developer the most flexibility and power possible. It stays in line with the majority of governance models, and safeguards the SharePoint production environments from preventable downtime and errors. As every developer knows, code that is still in development can cause unexpected problems. Using the model outlined here can prevent issues from ever affecting your company’s bottom line. It will protect people’s bonuses and jobs.