Centric connect.engage.succeed

Deploy software on external infrastructure

Geschreven door Hans Oude Middendorp - 17 oktober 2017

Hans Oude Middendorp
All software being developed at our company will be hosted either in our own data centers, in the cloud or on the infrastructure of our clients. Because source code is one of our most valuable intellectual properties, it was decided that we would host all our code in-house, using our own infrastructure. We have a “no source code in the cloud” policy, which is implemented in the internal networks of our company through our Team Foundation Server farm.

This policy has a large impact on the possibility of releasing software from Team Foundation Server: it is impossible to make a connection between the client’s infrastructure and our on-premises TFS farm.

Given the huge benefits, both in terms of traceability and time-to-market, of using release management tooling to release software, I decided to investigate the possibilities. In this post, I describe a feasible solution.


The basic idea of the solution is to install a release agent in the client’s environment and have it connect to Visual Studio Team Services (VSTS). A release definition in VSTS can deploy the software in the client’s environment. Client employees can also be added to the approval steps in the VSTS release definition. A release definition in our on-premises TFS farm will trigger a release in VSTS.

A release definition needs artifacts from TFS, VSTS or another build system. It is also possible to skip using artifacts this way and download the artifacts from another storage. In this solution we will use Azure Blob storage to temporarily store the build artifacts from our on-premises TFS farm.

The solution will work as described in the figure below.

This solution includes the following components:

  • TFS build agent: an agent running on an on-premises build server, executing build definitions from the on-premises TFS farm
  • TFS drop location: the location to which build artifacts are dropped; this can be a share on an on premises server or the on-premises TFS environment
  • TFS release agent: an agent running on an on-premises server, executing release definitions from the on-premises TFS farm
  • VSTS release agent: an agent running on a server in the client’s infrastructure, with sufficient rights to install software in the client’s environment
  • Azure Blob storage: Azure storage, used to temporarily store build artifacts from the on premises TFS farm
  • Client Infrastructure: the infrastructure at the client’s site on which software needs to be installed.

On-premises release definition

The on-premises release definition will need to contain a task that copies the build artifacts to Azure Blob storage and a task that triggers a build in VSTS. To copy the build artifacts to Azure Blob storage, we can use the “AzureBlob File Copy” task, which copies a file from a build or release agent to a location in Azure Blob storage.

On-premises release definition

You will be able to fill in the boxes using the information currently available on this task.

After copying the files to Azure Blob storage, the release would have to trigger another release in VSTS. Because no standard solution was available for this, I built a custom build/release task that does the job. I discuss this in my blog post: Trigger a release in an external TFS farm or VSTS. The sources are available here.

Once the task is added to the release definition it will look like this:

Release definition

The VSTS Account Name is the part between “https://” and “.visualstudio.com”. Access to the VSTS account is gained using a personal access token. I explain how to create a personal access token in my blog post: Custom build/release management task to execute a SQL script. Project Name is the name of the project in VSTS, and in the Release Definition box, you enter the name of the release definition that needs to be started in VSTS. A description of the release can also be added for traceability.

VSTS release definition

The VSTS release definition has no build artifacts. We do not define the artifacts for this release definition, and in the agent phase definition we select “Skip download of artifacts”.

The first step in every phase of this release definition is to get the artifacts from Azure Blob storage. Once again, no solution was available for this task, so I had to custom build one for our own use. Sources for this custom task are available here.

Adding this task to the definition will result in the following form:

VSTS release definition

In the Destination Folder you need to enter “$(System.DefaultWorkingDirectory)”. This way the contents of the Azure Blob storage will be saved to a location that will be accessible in the next steps of an agent phase.

Client Environment

The actual release phases and steps will run on agents installed in the client’s environment. We need to create one or more agent pools to administer this. The agent phases in the release definition will have to use this pool, so you’ll need to set this up in every agent phase. To prevent storing usernames and passwords in a release definition, it’s good practice to run the agents with service accounts that have just enough rights to perform the necessary changes on the systems where the software needs to be deployed to.

About Hans

Craft Expert Hans Oude Middendorp is part of the ALM team within Craft, the development programme for IT professionals (powered by Centric). If you would like to follow his blog, sign up for the monthly Craft-update.

Want to know more about Craft, the development programme for IT professionals? Check out the website!


    Schrijf een reactie
    • Captcha image
    • Verzenden