Language

Scenario: Configuring a Staging Environment for Web Deployment

By Jason Lee|

Download PDF

This topic describes a typical web deployment scenario for a staging environment and explains the tasks you need to complete in order to set up a similar environment.

Lots of organizations use staging environments to preview updates to web applications or websites. This gives people within the organization a chance to explore and review new functionality or content before the site "goes live," or in other words is deployed to a production environment. The staging environment is designed to replicate the production environment as closely as possible, in order to provide a realistic preview. This kind of staging environment typically has these characteristics:

  • The environment consists of multiple load-balanced web servers and one or more database servers, often with failover clustering and database mirroring.
  • Applications may be deployed manually by a development team or automatically by a Team Build server.
  • The users or process accounts that deploy applications are unlikely to have administrator privileges on the staging servers.
  • Changes to applications are deployed on a frequent basis, so the environment needs to support single-step or automated deployment.

Note: Scaling out a database deployment across multiple servers is beyond the scope of this tutorial. For more information on this area, please consult SQL Server Books Online.

For example, in our tutorial scenario, Team Foundation Server (TFS) manages the Contact Manager solution. The TFS administrator, Rob Walters, has created a build definition that lets developers trigger a deployment to the staging environment as required.

Note that in most cases, you won't necessarily want to deploy the latest build to the staging environment. Instead, you're a lot more likely to want to deploy a specific build that has already undergone validation and verification in the test environment.

Solution Overview

In this scenario, you can deduce these facts from an analysis of the deployment requirements:

  • The user or process account that performs the deployment won’t have administrator privileges on the staging servers, so the staging web servers must support non-administrator deployment. As such, you'll need to configure the staging web servers to use the Web Deploy Handler rather than the remote agent.
  • The staging environment includes multiple web servers, but it needs to support one-click or automated deployment, so you'll need to use the Web Farm Framework (WFF) to create a server farm. Using this approach, you can deploy an application to one web server (the primary server), and WFF will replicate the deployment on all the other web servers in the staging environment.
  • The user or process account that performs the deployment must have permissions to create databases. As such, you'll need to add the account to the dbcreator server role on the database server, in addition to configuring the database server to support remote access and deployment.

These topics provide all the information you need in order to complete these tasks:

Further Reading

For guidance on configuring a typical developer test environment, see Scenario: Configuring a Test Environment for Web Deployment. For guidance on configuring a typical production environment, see Scenario: Configuring a Production Environment for Web Deployment.

This article was originally created on May 4, 2012

Author Information

Jason Lee

Jason Lee – Jason Lee is a principal technologist with Content Master where he has been working with Microsoft products and technologies, especially SharePoint and ASP.NET, for several years. Jason holds a PhD in computing and is currently MCPD and MCTS certified.