Deploying a New Application

The following illustration shows the path that the SharePoint solution package (WSP) follows when you deploy a new solution. The path begins in the development environment and ends in the production environment. Although this configuration is a typical approach, there are many possible variations that are equally valid. In the illustration, the SharePoint solution is named wsp0 and contains all the solution artifacts for the application.

Deploying a new application

This scenario assumes the following:

• This is the initial deployment of a new application. All the required solution artifacts are defined in one or more SharePoint solutions.
• All the SharePoint solution artifacts are version-controlled with a source control system.
• The application can ship independently of any authored artifacts.
• Because this is an initial deployment, there are no existing records in the SharePoint content database that can conflict with the elements that are defined by the solution artifacts.

The Functional Testing and Integration Environment

The functional testing and integration environment (the test environment) performs manual functional testing, automated functional testing, system testing, security testing, and performance testing. Generally, some level of validation testing should run in the development environment before deploying the application to the test environment. The patterns & practices SharePoint Guidance team runs continuous integration and build verification tests (BVT) before it deploys the SharePoint solution to the test environment. The test environment can also be used to debug integration issues that developers cannot locally reproduce.

The test team controls when the SharePoint solutions are deployed to the test environment. Often, tests that are conducted in the test environment are referred to as black box tests. This is because no knowledge of the application's internal implementation is necessary to test the application's functionality. The environment is relatively stable, but it may have several applications deployed that are in various stages of development. Therefore, you should expect to encounter and resolve conflicts between applications in the test environment in addition to any problems that are not discovered in the team development environment.

Depending on the criticality and scale of the application, the test team may conduct performance tests to identify and resolve bottlenecks. Initial user acceptance testing is often also conducted in the test environment. After the test team is satisfied that the quality of the application meets production requirements, the SharePoint solutions are deployed to the User Acceptance Test (UAT) environment. For more information about how to set up the development and testing process, see Team Development Overview. For an example of how to deploy a new application, see An Example of Deploying a New Application.

The User Acceptance Test Environment

The User Acceptance Test (UAT) environment tests the deployment of the production-ready application in an environment that closely resembles the production environment. In older guidance, the UAT environment is named the staging environment. The name was changed to UAT because, in SharePoint, a staging server deploys content that still requires a final review to the production environment. The purpose of the UAT environment is to identify any potential deployment issues and to allow content to be reviewed by business owners. If the application passes these tests, the business owners sign off on the application. Although the UAT environment is optional for smaller applications where deployment failures are not critical, it is still recommended.

Only production-ready applications are deployed to a UAT environment. This environment represents the destination production environment as closely as possible from the perspective of topology (for example, the server farm and database structure) and components (for example, the inclusion of the Microsoft Active Directory directory service).

After the code is in the UAT environment, it is often labeled or versioned as final. This ensures the reproducibility of the final build. In more complex environments, the application may also be branched into a new fork of the revision control system. A recommended practice is to use a script to deploy and activate the application when you are deploying it to the UAT and production environments. This minimizes the opportunity for human error. The Partner Portal application includes installation scripts that serve as examples.

You should manually configure the SharePoint instance to duplicate the production configuration. Where governance permits, production data should be copied back to the UAT environment to create an environment that is as realistic as possible. Because the UAT environment does not need to be broadly accessible, you can secure the environment just as you would the production environment.

The Microsoft TechNet article, Move content databases between instances of SQL Server (Office SharePoint Server 2007), describes in detail how to move content databases between instances of SQL Server 2005. Use these instructions to copy the production SharePoint content database(s) to the UAT environment. Make sure to reattach the production content database(s) after the .mdf and .ldf files are in the UAT environment. The procedure in the article copies the entire content database that is associated with a site collection. If you have multiple site collections, it is advisable to copy all related content databases to the UAT environment.

If you want to copy only the contents of a specific SharePoint Web site, see Using Stsadm.exe to Migrate Site Data on MSDN. This may be useful if you have capacity limitations and it is not feasible to copy an entire content database.

For an example of how to deploy a solution to a UAT environment, see An Example of Deploying a New Application.

The Production Environment

After the UAT tests are complete, the application can be deployed to the production environment. Because the UAT phase emulates the production deployment, the deployment steps are identical, aside from any required name changes. For an example of how to deploy an application to a production environment, see An Example of Deploying a New Application. For publishing scenarios, there will often be an authoring farm for creating and approving content. This environment is also considered a production environment. Typically, solutions are applied to the authoring environment before or at the same time as the production environment. You may need to stagger the deployment if the changes impact the content in the production environment. In this case, you may need to perform the following steps:

1. Apply the solution to the authoring farm.
2. Make relevant updates to the production content in the authoring farm.
3. Apply the solution to the production farm.
4. Deploy the content to the production farm.

Home page on MSDN | Community site