It has been a while since I last blogged about MS Visual Studio Team Services Release Hub. The last time I blogged about Release Hub the product was very much rough around the edges and quite a few of its parts were in early preview.
Release Hub has matured quite a bit since then, however deploying to production or test environments in the real world can be considerably different compared to the examples of using Release Hub available online. The items I find many customers I go and see have difficulty with is where the documentation is very much sparse or spread around many older versions of the product is:
The sample I have put together here is more for my own reference. But if you have any suggestions or improvements I would love to hear from you. I will try to expand on this article a bit more with more examples that don’t fit the norm in future blog articles.
The scenario I am going through here is an ASP.NET website that is created from a build and that same build needs to be deployed to more than one environment with its configuration changed for each environment.
The steps involved will be to
Before you can deploy a web project you need to prepare your project for deployment. You may have already used this functionality to deploy directly to an Azure website from Visual Studio or to an on premise server. This functionality can also be used to help create deployment packages that we will use later with Release Hub.
Step 1Right click on your web project and select Publish. Don’t worry this wont publish your site but it will enable us to setup a deployment profile for it that we will use later.
Step 2From the dropdown that appears select “New Custom Profile” and type in a name for your new profile and select Ok. In this case our profile is called “Website1WebPackage”
Step 3In the dropdown box that appears next select “Web Deploy Package”, here type in a name for your deployment package. We will be using MS Web Deploy to deploy our site later but in order to do this we need to set our site up to create a deployment package. In addition to this we are placing in a token called __SITENAME__ this will be replaced later at deployment time when we actually deploy our application. I will talk more about this later.
Step 4 Here the publish wizard will display any database connections string which you can also replaces with tokens of your own. Tokens start with “__” and end with “__” and are in capitals.
Step 5You can now hit the publish button. All this will do is create a webdeploy zip package in the root of your project . You should now see the following files
We are only really interested in the website1.webpackage.SetParameters.xml and in website1.webpackage.zip. These files when using the correct switches on your build, will be generated each time. if you open up the parameters file you will notice it contains the tokens we created earlier.
Step 6In the root of your web project create a parameters.xml file . You will see in our parameters file we are using an xpath match to replace settings in our web.config file. The scope is basically looking for a database connection string called DefaultConnecction and we are saying that when you find that value replace it with __DBCONNECTION__ we are doing the same with another key in our web.config called MailAddress.
<?xml version="1.0" encoding="utf-8" ?>
<parameter name="DefaultConnection" description="DB Connection" defaultValue="__DBCONNECTION__" tags="">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/connectionStrings/add[@name='DefaultConnection']/@connectionString" />
<parameter name="EmailAddress" description="MailAddress" defaultValue="__EMAILADDRESS__" tags="">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[@key='MailAddress']/@value" />
You can see how the parameters above relates to the web.config below
Step 7Publish your project again by right clicking on the project and selecting publish and then the profile you created earlier. If you know check the setparamters file. You will notice the new tokens we added in the parameters.xml file are also in here. This file automatically updates with these tokens when you run the publish profile and is key to how we can replace variables in our configuration files.
We are now ready check in our code and to create a build. Ensure you check in the parameters.xml file and your new publish profile (highlighted below)
Step 1You may already have a build for your solution, if so you can alter this build to produce the assets you need for deploying your solution. Below I have setup an out of the box Visual Studio build pointing to my solution however I have added some arguments to my build.
Those arguments are:
/p:DeployOnBuild=true;PublishProfile=Website1WebPackage /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
Note above that our publish profile is set to the one we created earlier in the tutorial when we prepared our ASP.NET project with a publish profile we called it “Website1WebPackage”. We are also telling MSBuild that we want it to create a package for us and that we want everything to be in a single file.
Step 2Click on the Copy Files to task and in the contents textbox you will see we have two entries. We are telling this task that all we want from the finished build is website1webpackage.zip and the website1webpackage.SetParameters.xml file we covered in the earlier steps. These files are automatically generated by our build after we had setup a publish profile on our build to create them in the earlier steps.
Step 3Run your build and at the end of the build if you look at its artefacts you should have the following files. We will use these in our release to help with tokenisation.
Step 1Go into Release Hub and create an empty release.
In this example I am using the build I created in the previous steps.
Step 2If you don’t already have it, you will need to go to the VSTS market place and select a Tokenisation task. I like to use the following https://marketplace.visualstudio.com/items?itemName=TotalALM.totalalm-tokenization but there are several more you can choose from.
Step 3Add your tokenisation task. In mine I have set the working directory of my solution as the target path using the following VSTS token $(System.DefaultWorkingDirectory). I have set the Target Filenames to the SetParameters file that our build we created in the previous steps is generating.
Step 4In the environment I was working we weren’t allowed to use Windows File Copy as it was considered insecure. However we did have WINRM available to us. Provided you have PowerShell 5 installed it is possible to copy files from a PowerShell command line to your destination server. You can skip this task and use the Windows FileCopy task if this is open on your network.
In my example I have done just that using the PowerShell task. The PowerShell I use is below and tokenised by variables stored in VSTS in the variables tab.
$password = ConvertTo-SecureString "$(password)" -AsPlainText -Force
$cred= New-Object System.Management.Automation.PSCredential ("$(username)", "$password")
$session = New-PSSession -ComputerName myserver01
Copy-Item '$(System.DefaultWorkingDirectory)\WebApp1 Build\drop\WebApplication1\website1webpackage.zip' -Destination 'c:\drops' -ToSession $session
Copy-Item '$(System.DefaultWorkingDirectory)\WebApp1 Build\drop\WebApplication1\website1webpackage.SetParameters.xml' -Destination 'c:\drops' -ToSession $session
I am basically using PowerShells Copy-Item command here to get the files to the server for me to a folder on the c drive of the server called “drops”. I get the path to the files by temporarily making use of a Windows File Copy task to show me the path variables and then delete it after
Step 5Now that I have setup my WinRM file copy I can then use the IIS WInRM Task to deploy to my web server
In the example I am using the package files that were copied to the web server in the previous step.
Step 6Remember those tokens you setup in the previous steps? Now is the time to start giving them values. Click on the Variables tab and start putting some entries in for those tokens. You will also notice that the username and password we use in our release tasks are also stored here and we can refer to them as $(username) or $(password).
Step 6You should now be able to run your Release and deploy.
Step 7 (Optional)If you have more than one environment, you can clone the existing environment and then replace the server names with the next environments server names.
Email Rory Street
© Copyright 2017 RippleRock