In my previous post I showed how to host a private agent to build your solutions on-premise. Today I’m going to show how to release from Visual Studio Team Services to on-premise servers using Web Deploy and a private agent.
Just like the build experience the release management features got an overhaul in VSTS, the previous Release Management product is now rolled into VSTS and TFS Update 2. Most of the current functionality is focused on releasing to Azure but you can use PowerShell or the command line to execute your own install scripts.
For this demo I’m going to release a simple web application using a web deploy package. You could deploy to IIS using remote agent deployment straight from the VSTS servers to on-premise but that is not always possible or allowed in secure environments. When you build a web deploy package the build process will retrieve some settings from you local IIS instance to set some defaults for the package. This won’t work if you use a hosted agent, I’ll be using my private agent for building as well as releasing the web deploy package. In a future post I’ll dive into web deploy in more detail but for now I’ll be using the defaults for deployment since the post is about VSTS release management not web deploy.
Firstly you have to modify your build and pass in the arguments to instruct MSBuild to create the deployment package, as shown here:
I’m only interested in the deployment package output from the build process so I’m going to publish the deployment package folder to my artifact output.
In Visual Studio set your publish settings for the web deployment package, take note of the package location, it is the folder you specified in the artifact publish step and I’m creating it in the root of the solution folder to keep things easy. Check the change in and kick off a build.
Back in VSTS open the release menu. To create a new release, click on the + sign to create a new release definition and start with a blank definition.
This demo deployment will have only one step to execute the web deploy package with its default parameters. Click on Add tasks and choose Command Line from the Utility sub section. To get the correct path to the web deploy .cmd file you can browse the artifacts published in the build step. Remember to save the new release definition you created.
I’ll cover the details of environments and different release types in a future post but for now this will be a manual release to the default environment. Access the context menu for the definition you created and select Release.
On the next screen accept all the defaults except under artifacts select the latest build of your code and click Create. This will not launch the deployment yet since we are doing it manually. If you look at your list of releases you will see a new release definition. Double click this release and click on the Deploy menu item and deploy to the default environment.
Once the deployment is completed, you will see the new web application in IIS using defaults picked up from your solution.
This was just one way of many to accomplish on-premise deployments, if you look at the example from MSDN, they are using WinRM and DSC to install IIS, WebDeploy and to install the web app.
Note: On the destination IIS server you also have to take some steps to set up IIS for deployment. You have to install Web Deploy and the easiest way seems to be Web Platform Installer. Also make sure the IIS Management Service feature is installed.
Wont this require Visual Studio or at least the Build Tools installed on the server where the private agent is located?
Yes you need the VSTS agent installed on a machine inside your network. To use that agent to build it is easiest to install Visual Studio instead of installing individual components.