What is the Staging Environment?
The staging environment lets you move Web site assets within and across different environments. For example, you can move a new Web page or a marketing campaign from a test environment to a production environment. In an enterprise deployment, you can define staging projects to move content from the development environment to the test environment, from there to the staging environment, and from there to the production environment.
The staging environment consists of two components:
The staging database server.
The staging server.
Staging Database Server
The staging database server contains the business data, such as marketing campaigns and product catalogs, and database resources that you want to stage to the database servers in the production environment.
Business users can update business data in the staging environment so that you can test and approve the changes before you incorporate the changes into the run-time environment. The staging environment prevents disruption of the run-time site and services by isolating the test and production systems.
Staging Server
The staging server is a mirror of the production business management server.
You create staging projects and routes on the staging server to deploy site updates from the test environment to the production environment. You can also use the staging server to deploy updates to geographically distributed environments across a wide area network (WAN).
For example, business users and internal developers might update various aspects of the retail Web site at your headquarters in New York, where your test and production environments reside at the local data center. However, you might also maintain production environments in Seattle, Los Angeles, and Chicago. Therefore, you can use Commerce Server Staging (CSS) on the staging server to deploy local site updates to the production servers in other remote cities.
You alter the Web site in a pre-production environment in order to be able to validate your changes prior to pushing them in production. Workflow processes can be implemented to take advantage of SharePoint approval mechanism. After the changes have been approved, a content deployment path between pre-production and production can be created and deployment jobs can be created for these paths. These job can move content between farms on a scheduled basis or the jobs can be manually run. The jobs can use full push to production or incremental. For information about planning content deployment with SharePoint Server, see https://go.microsoft.com/fwlink/?LinkId=139665.
See Also
Other Resources
Building the Staging Environment