This is the final part of a four-part series on using Team Foundation Server and Team Build to set up a continuous deployment environment.
- Part One: Getting the lay of the land.
- Part Two: Preparing the Project for Continuous Deploy
- Part Three: Creating the Team Build for Continuous Deploy
- Part Four: Performing Parameterized Deployments with Web Deploy
In this post, since I didn’t get all the way through deployment, we walk through setting up MS WebDeploy, as well as setting up environment specific deployment parameters.
IIS Web Deploy must be installed on the target server hosting your web application in order to enable continuous deployment from a TFS build. Since Web Deploy was a prerequisite from the last post, you should have an installer available that you downloaded from http://www.iis.net/WebDeploy. Follow these steps to install and configure it:
- Run Web Deploy_amd64_en-US.msi (MS Deploy component) and choose Complete installation.
- Create IIS Management User
- Create IIS Management User and note the user name and password that you use. This credential information is passed as part of the MSBuild parameters specified in your build definitions (see the MSBuild Arguments section of the part 3 of this series).
- Grant the IIS Management user you created access to your website.
- IIS Management Service Delegation
- Check to make sure that setAcl, createApp, dbFullSql, contentPath, iisApp delegation rules were created by MS Web Deploy installation.
- IIS Management Service ACLs
- Grant LOCAL Service (the account used by WMSVC) Full Control of the physical folder of your application.
Once MS Deploy is installed and configured on the target IIS, the MSBuild Arguments specified in your TFS build definition should be able to successfully publish the packaged content of your application to IIS on your host machine. The end result of which is that a versioned, labeled set of artifacts is published each time a successful check-in is completed.
So now that you are continuously integrating and deploying your code, you might want to smoke test it and, if it passes muster, deploy that same version to a different environment. Fortunately, if you are using the /p:CreatePackageOnPublish=True MSBuild parameter, the bulk of the work has been done for you. The package that is created by the MSBuild pipeline contains a deployment script named <YourProjectName>.deploy.cmd which knows how to perform a publish action very similar to the one already performed by TFS. Now all we have to do is modify environment specific settings so that we don’t inadvertently use our dev integration environment.
To enable environment specific deployment parameters, add a Parameters.xml file to your Web Application project. This file is a design-time artifact that will be used by MSBuild to insert placeholders into the configuration files based on values that you specify. For example:
Given a web.config containing a node like this:
And a parameter.xml file like this:
MSBuild will look for a node that matches the XPath specified in the “match” attribute inside the web config file specified in the “scope” attribute and replace it with a tokenized value when constructing the package.
One thing to note about package parameters is that connection strings are automatically tokenized so you do not have to add them to your custom Parameters.xml file.
Refer to Microsoft’s documentation for more information: http://msdn.microsoft.com/en-us/library/ff398068.aspx.
At deploy time, any file named SetParameters.xml that is present where the cmd file is run will be used to replace the tokenized parameters based on the name of the parameter.
Given a SetParameters.xml file containing this:
The token based on the parameter named “AServiceEndpointAddress” will be replaced with a URL that points to the prod.server location of the service.
For our projects, we add a SetParameters.xml for each of our environments with the following naming convention <Environment>.<ProjectName>.SetParameters.xml.
If you examine the contents of the application package, you will notice a readme.txt file that contains instructions for running the associated <ProjectName>.deploy.cmd. It accepts several different switches, but the most important to understand are those that control the mechanism for performing the WebDeploy.
/Y A flag that will cause the deploy perform the publish. An alternative is to use /T to test the deployment which reports on the publish activities, but doesn’t actually publish content.
/m:<deployserver> The url of the host machine you are deploying to. Remember that MS WebDeploy must be installed on the server.
/u:<username> The name of the identity that has permission to perform the deployment. Use the same IIS Management User created for the continuous deployment in your build.
/p:<password> The password of the identity that has permission to perform the deployment.
For our projects, we create a simple batch file that accepts a parameter indicating the target environment. The parameters xml file that matches environment is copied into the deployment folder and renamed to <ProjectName>.SetParameters.xml so that the cmd file will pick it up and apply the environment specific values.
Through the course of the four posts in this series, we presented a way to use TFS’s Team Build facilities to verify every check-in with unit tests and deploy the integrated and versioned code to a smoke testing environment and then later deploy the exact same version to a different environment. The value of reducing cycle time from code to deployment and failing early in a predictable way cannot be over-estimated. We also find that our development teams increase productivity by reducing time performing manual deployments and verifications.