The following is an excerpt from ASP.NET MVC 2 in Action, a book from Manning to be in bookstores in May. The early access (MEAP) edition is available now on http://manning.com/palermo2. Authors include Jeffrey Palermo, Ben Scheirman, Jimmy Bogard, Matt Hinze. Technically edited by Jeremy Skinner.
17.4 Enabling remote server deployments with Web Deploy
After getting a deployment script that can set up your application and database, the next step is to take on the challenge of pushing deployments to multiple servers. The key takeaway is that by automating the task of deployment, you can eliminate all the manual steps that are prone to errors.
In order to eliminate the need to log on to servers one by one, an additional technology is needed. This is where the Web Deployment Tool (formerly named MSDeploy) comes into play. You can download it from http://www.iis.net/expand/webdeploy. This tool provides a host of features and functions, , but the features most important for our deployment approach are
- The ability to sync files over HTTP
- The ability to execute a remote command
These features support both enterprise and hosted environments, and the scripts can be used for both preproduction environments and production environments.
Typically, for web applications, there will be a development server that hosts the web application and database on the same machine. The quality assurance (QA) environment may be set up the same way. Then, in the staging and production environments, more servers come into play. There may be a separate database server, multiple web servers, and even an application server. Automating a deployment to multiple machines can become complex very quickly. In order to reduce the complexity, Web Deploy can be used to sync files to multiple machines and execute the deployment script on each server. It can also run remotely so that deployments execute the same way that they would in the development environment.
Listing 17.4 shows the command-line arguments used to copy deployment files from a build server to a web server and then run the deployment.
Listing 17.4 Using Web Deploy to remotely execute a deployment
msdeploy.exe -verb:sync -source:dirPath=deploymentFiles |#1
-dest:dirPath='c:\installs',computername=192.168.1.34 |#1
msdeploy.exe -verb:sync |#2
-source:runCommand='c:\installs\dev.bat' |#2
-dest:auto,computername=192.168.1.34 |#2
#1 Copy files to remote server
#2 Execute command on remote server
First, msdeploy.exe is called with the sync verb specifying a source directory on the local machine (#1). This command copies all the files inside the deploymentFiles directory (C:\installs) to the remote server (in this case, the computer with the IP address 192.168.1.34).
Next, msdeploy.exe is called with the sync verb, but this time the runCommand argument is specified (#2). This means that Web Deploy will execute the batch file at c:\installs\dev.bat on the remote server in the same way you would run it if you logged in via remote desktop.
Using a technology like Web Deploy can greatly simplify a complex deployment. By running each command locally on each server in the deployment, scripts will run consistently from the development environment through the production environment. The real advantage is that the calls to msdeploy.exe can be scripted, which means that a multiserver deployment can be totally automated and repeatable. Scripting this type of deployment also means that from a single machine you can monitor a deployment and see the results of each script consolidated on your desktop.
17.5 Summary
When we configure our environment, we must devise a reliable deployment strategy to ensure that the right application is deployed with the correct configuration. At the heart of a solid deployment strategy is continuous integration, which includes practices such as automated deployments and self-testing builds.
With free, widely used open source tools such as CruiseControl.NET, NAnt, NUnit, and others, we can create an automated build and deployment server. By packaging NAnt, a build script, and a bootstrap batch file, we can harness the flexibility and power of NAnt to deploy and configure our application to multiple environments, up to and including production. By layering on the Web Deploy tool to reduce the friction of copying and executing the build scripts across multiple servers, we can have a totally automated solution that’s repeatable and reliable.
You will notice that the raw files in GitHub are released under the 
RSS
