Using MSDeploy to Automate Web Deployment for Test and Production with Visual Studio ALM 2010 Team Build
Leverage MSDeploy.exe to Automatically Deploy Builds Where We Need Them
In an earlier posting Building a Custom Build Workflow with Deployment I showed how you can extend Team Build workflow to do a simple deployment to a user acceptance test (UAT) location. Here I'll discuss improving that example with the powerful capabilities of MSDeploy.exe. You can download the PowerPoint slide deck and Word document from my code camp and user group presentation for an overview and details of the MSDeploy.exe command line reference.
MSDeploy.exe is the engine behind Microsoft's Web Deployment tool. It assists in deployment, migration and synchronization of web applications and sites from one location to another. The locations can be local or remote, requiring a remote agent service. IIS must already be installed on the source and destination computers. MSDeploy has numerous features that let you, with a great degree of precision, include those components that you want to process and exclude those that you do not.
- Synchronize
- Coordinates source and destination
- Locally or remotely
- High degree of precision including dependencies
- Package
- package and archiveDir let you snapshot into .zip of archive directory
- Parameterization and manifest let you customize
- Deploy
- Implement or test with whatif
- Computer to computer directly or use packages
- Features for troubleshooting
MSDeploy.exe Command Line
The Msdeploy.exe command-line executable file that implements Web Deploy functionality contains many powerful features. A Web Deploy verb specifies the action to be taken, such as synchronization (sync. The -source and -dest arguments define the source and destination of the data to be deployed. Typically, a source or destination is a Web site or Web server. A variety of predefined source and destination object types are available in the form of providers. Providers let you access and synchronize Web sites and Web servers, metabase and ApplicationHost.config configuration information, archived Web sites and Web servers, file and directory paths, and other IIS-related data. For more information about providers, see Web Deploy Providers.
Principal elements are a verb (also called an operation), a source, an optional destination, and optional operation settings
msdeploy.exe -verb:<verbName>
-source:<provider>[=<pathToProviderObject>
[,<providerSetting>=<providerSettingValue>]]
[-dest:<provider>[=<pathToProviderObject>
[,<providerSetting>=<providerSettingValue>]]]
[-<MSDeployOperationSetting> ...]
Verbs are delete, dump, getDependencies, getSystemInfo, and sync
Web Deploy has additional arguments that let you refine the meaning of providers and their sources and destinations. Operation settings modify how the command runs. Rules modify the behavior of operations. Link extensions let you pull together data in ways that would not otherwise be possible. These features combine to enable you to implement custom Web deployment scenarios with maximum power and flexibility.
Using MSDeploy.exe in Team Build
If your destination is remote, you’ll need the Web Deploy remote service installed and running on the remote machine. Best practice is to check for dependencies before a sync operation with getDependencies and resolve conflicts and unsupported components. Backup the destination as appropriate, then create your command and test it. Note: use whatif first and check the output.
msdeploy -verb:sync -source:
,computerName= -dest:
-whatif >msDeploySync.log
After you have verified it is doing what you want, you can run without the whatif. When it tests successfully you’re ready to move to implementing your deployment in Team Build workflow.
You can refer to my pervious post for creating a custom build and navigating the build workflow. In the "Try Compile, Test, and Associate Changesets and Work Items" activity, I expand the Finally block and added a new activity at the end called "If DropBuild Successful". Here I'm expanding the activity:
Note the condition. When it resolves to true, the Then block will execute. I've added an activity of type Sequence called "DeployUAT" that contains our actual deployment functionality. Since we only want to deploy to our UAT manually, I have added an Invoke for Reason activity and named it "InvokeOnlyForManual". You should see the dropdown for Reason set to 'Manual" in the properties.
I have scoped new variables and arguments to the "DeployUAT" activity. These allow us to define where our UAT site is located and what it's name is. Click on the Variables and Arguments tabs at the bottom of the designer.
While on the Arguments tab, open Metadata. Here I have defined a new category that will show up in the build process dialog. I have named this category "Deployment" and it displays our 2 new parameters with their default values.
Now to move on to the actual work of deployment. In my previous post example we had to do several individual steps in order to perform a clean deployment. With the power of msdeploy, we can do it all with one activity that I have named InvokeSyncWebsite.
Save your XAML file and check it in to source control. You now have your custom template ready for use. Below you can see our Deployment category that we added to the template process. The default values can be over-ridden when the process is manually called.
This example should get you started using msdeploy for deployment to your builds. There are many more considerations you may have to make for your particular implementations including, security, domain and firewall boundaries. We have just scratched the surface of msdeploy's capabilities.
Download Custom Process Template MSDeploy_