The IIS Web Deployment Tool (Web Deploy) and the deployment features introduced in Visual Studio 2010 enable you to automate many deployment tasks, but we have heard you all that many common scenarios not yet documented fully. We are addressing this need by creating step-by-step walkthroughs that will guide you from beginning to end through scenarios that address common real-world needs.
UPDATE: We just published the Enterprise Deployment Series which can be found at:
- Enterprise Deployment Series Introduction: Deploying Web Applications in Enterprise Scenarios (3 Tutorials)
- Enterprise Deployment Series 1: Web Deployment in the Enterprise (11 Tutorials)
- Enterprise Deployment Series 2: Configuring Server Environments for Web Deployment (11 Tutorials)
- Enterprise Deployment Series 3: Configuring Team Foundation Server for Web Deployment (7 Tutorials)
- Enterprise Deployment Series 4: Advanced Enterprise Web Deployment (9 Tutorials)
Interestingly, remaining of this blog post is not the documentation of the solution but actual articulation of problem statements. This post presents the first set of scenarios that we have identified and solicit your feedback to help us determine they are representative enough or not. If you have any feedback as usual you can post them here as comments or feel free to send me an email at Vishal.Joshi@Microsoft.com.
Scenario 1: Enterprise Deployment with Continuous Integration
In this scenario, a solution that includes multiple web application projects is deployed to test, staging, and production environments, using a continuous integration process for staging and production.
Target Environments
The TESTING environment consists of a server that runs IIS 7.5 and a server that runs SQL Server 2008 R2. The developer machine has a network connection to the test servers, and the developer uses one-click publish to deploy to testing environment.
STAGING consists of a web farm (2 servers running IIS 7.5) and a database server that runs SQL Server 2008 R2. The developer machine has network access to a TFS server that acts as a source code repository, and the TFS server has network access to the staging servers. (The developer machine does not have direct access to the staging environment, and the developer does not have administrative rights on the staging servers.) Team Build builds the Visual Studio solution, runs unit tests, and publishes to staging. Each time that Team Build performs build and deployment, it simultaneously creates a deployment package (web deploy .zip file) for use in deploying to production.
The PRODUCTION environment mirrors staging except that a firewall (or perhaps even different domains) prevents direct access for publishing from the TFS server to production. When a build is approved for production, the IT department uses the package created when TFS publishes to staging to deploy to the production servers.
The diagram below illustrates this scenario:
Enterprise scenarios may have a QA environment set up in a manner similar to staging; however, for the purposes of demonstrating how to set up deployment it's not necessary to include that here, because the process would be similar to the process for setting up staging.
Visual Studio Solution
The Visual Studio solution to be deployed consists of multiple web application projects, a class library project, and a unit test project. Deployment must take into account the following considerations:
- One of the projects uses ASP.NET membership functionality, and the membership database must be deployed. Account information can be deployed to test but not to staging or production.
- One of the projects uses a SQL Server database that is accessed using the Entity Framework (Database First, using an .edmx file). On initial deployment to any environment, only the structure (schema) should be deployed. For any database deployment after the initial deployment, data already entered online in that environment must be preserved.
- The class library project creates an assembly for a custom control that is used in one of the projects. This assembly needs to be installed in the GAC as part of the deployment process.
- The custom control gets a default value from the registry. The registry value needs to be different in each environment and needs to be updated when the solution is deployed. (This particular use of registry settings is not common, but updating the registry is a common need, and this provides a simple way of integrating a registry update into the scenario.)
- The Web.config file contains settings that must be different for debug vs. release builds, and settings that must be different for different target environments.
- One of the web projects includes a folder for log files. The deployment process must not copy files in this folder from source to destination and must not delete files from the folder on the target server.
- IIS settings for error handling and authentication must be set up on the target server during deployment. For the test environment these can be the same as the settings on the developer machine, but for staging and production the settings are different.
Some additional deployment considerations apply only to the automated deployment from TFS for staging and production:
- Deployment should occur only if the unit tests are successful.
- The web projects need to be precompiled before deployment.
- The IIS settings for staging and production are taken from IIS on the TFS server. (This is a limitation of the current release of Visual Studio and Web Deploy; when the walkthroughs are updated for the next release of the software, hopefully IIS will not be required on the TFS server (keeping fingers crossed
)
- App_offline.htm must be set up at the start of deployment and removed at the end.
- Deployment activities should be logged. When deployment completes or fails, email notifications should be sent to designated recipients.
- If deployment fails, the previous deployment's package should be redeployed, or the current deployment should be retried.
Tasks Illustrated
The walkthroughs for this scenario would guide you through the following tasks"
- Downloading the Visual Studio solution to be deployed.
- Setting up the test server.
- Using one-click publish to deploy to testing servers:
- Initial deployment.
- Redeployment without a database change (for example, an update to code in a web page).
- Redeployment after making a database schema change.
- Setting up staging and production servers.
- Setting up the build server.
- Three deployments to staging (initial, web page change, database change).
- Three deployments to production (initial, web page change, database change).
For the Visual Studio 2010 version of the walkthrough, database updates will involve running custom SQL scripts as part of the deployment. The scripts will be created manually; tools such as TSData and Red Gate can be used to generate such scripts, but those tools will not be covered in these walkthroughs. Eventually we will look at smoothing this flow as well.
Scenario 2: Enterprise Deployment for MVC and Entity Framework Code First
This is a variant of the first scenario that differs from it in the following ways:
- The web projects are MVC instead of Web Forms.
- Entity Framework Code First is used instead of Database First (no .edmx file).
- TeamCity is used instead of TFS.
Scenario 3: Enterprise Deployment for Web Site Projects
This is another variant of the first scenario that differs from it in the following ways:
- The web projects are web site projects instead of web application projects or MVC.
- Web Deployment Projects (WDP 2010) are used.
- One-click publish is not available for web site projects, so a web deployment package is used for deploying to test.
For those of you who work in enterprise environments, do these scenarios adequately represent the kinds of challenges you face in deploying ASP.NET web applications? Are any key pieces missing? We cannot answer every question in these walkthroughs, but if there are other issues commonly faced by your team, we can add solutions for them to the walkthroughs as well.
Your thoughts and feedback are welcome. Also I want to thank Tom Dykstra, Bilal Aslam & Sayed Hashimi on our team who will be helping on putting together a lot of this content for you.
FEB 2012 UPDATE: The work on these scenario documentation has started happening. The tutorials are still being written but the sample app with an initial draft of the first part of the tutorials is available on MSDN:
http://code.msdn.microsoft.com/ASPNET-Enterprise-Web-6b2ad7cf
(The tutorials are in Word docs in a folder in the sample project.)
They’ll be published on the ASP.NET site most likely in the next couple of months.
Thanks for reading!!
-Vishal
