Deploy artifacts from OnPrem TFS server with Release Management Service

Summary

Did you know you could consume artifacts from build definitions on an OnPrem TFS Server and deploy your applications using the Release management service in Visual Studio Team Services, that too without exposing the TFS Server to the internet?

Did you know that you could also deploy the applications to a OnPrem target environment using the service?

Did you know that all this happens without the artifacts leaving the secure and strict boundaries of your enterprise network, thereby ensuring you are safe from any information leaks?

In this blog, we shall talk about a walkthrough of consuming artifacts from an OnPrem TFS 2015 Server and deploying them to a target machine.

Pre-Requisites

Before we go through the steps, it is assumed that –

1. You have configured a build definition on the OnPrem TFS Server that’s publishing artifacts on the server.
1. The published artifacts consist of the binaries for the application and a powershell script that can deploy the application on a target server.
2. Note that at the moment, the build should publish a single artifact called “drop” in order for the deployment to work.
2. The target server on which the application should be deployed in configured for WinRM
3. Additionally, you have another machine prepared with WMF 4.0. This machine (we shall refer to it as the agent machine henceforth) should have access to the TFS Server and the target server. 

Configuring an Agent

On the agent machine, you must install and configure a release agent. This shall act like a bridge between VS Team Services and your OnPrem network, facilitating the services to perform and monitor the deployments.

Follow the steps mentioned here (you can also watch the agent configuration in action here). Note that it is advised to login as the account owner for VS Team Services while configuring the agent.

Once you’ve done this, you would be able to see the agent listed in the default pool.

You shall also be able to find it listed with the default queue.

You can read more about agent pools and queues here

Create a Service Endpoint for the TFS Server

To consume builds from TFS server, you must first create a service endpoint with credentials to connect to TFS Server.

In a way, this is an authorization for VS Team Services to request the agent to fetch information from the TFS Server. The information (artifact binaries) is fetched and stored on the agent machine only. It is not shared with VS Team Services.

Also, the credentials are stored in an encrypted form not accessible to anyone.

These facts coupled with all communications to/from VS team services being over HTTPS ensure that the security of the enterprise network/ TFS Server is not compromised by doing so.

Set up the TFS endpoint in the Services tab of the Control Panel for your team project. Use a Generic endpoint, and enter the TFS server URL and credentials to connect to the TFS server. For more details, see Service endpoints.

1. The Server URL needs to be upto the collection. For eg.  http://example.com/tfs/DefaultCollection
2. The username and password would be domain credentials to authenticate with the TFS server. These would not be tested/validated. Any mistake in these would be detected only when you run the release.

Create a Release Definition

We are now all set of start defining our deployment pipeline and configure continuous delivery for the application.

1. Goto the Release hub in a team project on VS Team Services
2. Click on New Release Definition and choose to start with an Empty temple

3. In the empty release definition, we’ll first link to the build definition and define the source of artifacts to deploy.

4. Select the endpoint we defined above and provide the values for the project name on the TFS 2015 server and the build definition defined on it.

5. For the “default environment”, add tasks to configure the deployment steps. In our case, we want to execute a powershell script on the target server with the artifact present locally on the target. We shall add the following two tasks for it and update the task parameters.
1. Windows Machine File Copy

• The source location for the payload would be “$(System.DefaultWorkingDirectory)\\drop”

Create a Release

Follow @vsreleasemgmt