We will see how to implement this solution (the Microsoft documentation is available here). To start, you need to be sure to have the following requirements:

Before starting, you must deploy on your ACS, the VSTS agent.

You need a token to install this agent. Go in your VSTS > Your account > Security :

VSTS agent security

Click on Add to create a new token:

VSTS agent personal access token

Select Agent Pools (read, manage) for the permission and create the token:

VSTS agent personal agent tokens agent pools

Save the key that VSTS will generate because you’ll not be able to get it later. Connect to a server where Docker is available to install the VSTS Agent (you can deploy this agent on a Docker container). My server is on Ubuntu 16.04. In the VSTS interface, click on Settings > Agent queues > Download Agent and select your OS:

VSTS interface Settings Agent queues Download Agent

Download the agent from the server and execute the configuration command by replacing the URL of your VSTS. Provide the token that you created just before for the authentication:

VSTS token script

The agent is now configured. To start it, execute the script ./run.sh:

VSTS token script

To give the possibility to each component to speak each other’s, you need to install the Docker component on VSTS. It will allow the communication between your VSTS and your Docker environment. On the marketplace of Visual Studio ( https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker ) click on Install:

Visual studio marketplace Docker Integration

Choose on which VSTS account to install the Docker Integration component:

Docker Integration component

Docker Integration procced the account

To continue, get a GitHub token who has permissions repo, user, admin:repo_hook :

GitHub personal access tokens

The next step is to associate your VSTS and your GitHub account. Open the project and click on Settings > Services:

VSTS Settings Services

Here, click on New Service Endpoint > Github:

VSTS New Service Endpoint Github

In the new window, provide the token that you generate before and the name associated with this token:

Add new GitHub service connection

Visual Studio Team Services new service endpoint

It is necessary to register the Docker registry, by clicking on New Service Endpoint > Docker Registry:

Visual Studio Team Services new service endpoint docker registry

Provide information of your registry, that you can find on Azure, in the menu Container Registry > Access Key:

add new docker registry connection

Visual Studio Team Services new service endpoint details

To finish this part, you need to add a new service, SSH. Give a name, the URL to connect that you can find on Azure, in the Container Service part, the port (2200 by default), the username that you provide when you created the ACS and finally, the private key used during the installation of the ACS:

update authentification private key ssh

Visual Studio Team Services new service endpoint details

VSAN from StarWind eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on the off-the-shelf hardware. Such design allows VSAN from StarWind to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses.
Learn more about ➡ VSAN from StarWind.

The configuration part is now finished. Move to the next. We will start by creating the base of the build. Navigate to VSTS, in Build & Release. Click on New > Empty:

Visual Studio Team Services create new build definition

Click on Github and select Continuous integration. Choose the type of the agent, Default:

Visual Studio Team Services github continuous integration

On your new definition, click on Repository and select the Github account that you configured before, thus the repository that you want to use for the CD:

Visual Studio Team Services definition new empty definition

On Triggers tab, select Continuous Integration. This will activate the trigger when you will do a commit on the application:

Visual Studio Team Services New empty definition Continuous integration

Click on Save:

Visual Studio Team Services new empty definition save

My application, that I want to deploy, contains one image, nginx. I’ll create 2 Docker steps, one to send the image to ACS and one on ACR. Click on Add build step… in Build:

Visual Studio Team Services definition add build step

Choose Docker and click on Add 2 times (for ACS and ACR):

Visual Studio task catalog build docker compose

For the first build, select the connection to your registry, the action Build an image, the path to your Dockerfile who is on Github, the path to sources and to finish, the name of your image, with the full path to your registry:

Visual Studio Team Services build an image

For the push part of your Registry, select the connection to your registry, the action Push an image and the name of your full image to your registry:

Visual Studio Team Services push an image

To finish, you need to add the following step, only if you have a docker-compose.yml file, for multi-tiers applications. Otherwise, go to the next step:

  • Command Line ()
    • Tool: bash
    • Arguments: -c “sed -i ‘s/BuildNumber/$(Build.BuildId)/g’ sources/docker-compose.yml”

And for everyone, you need to add the step for the publication of the artifact, with sources:

  • Publish Build Artifacts
    • Path to publish: sources
    • Artifact Name: FloAppWebsite2
    • Artifact Type: Server

Visual Studio Team Services publish artifact

Click on Save to save the configuration.

After that, create the new configuration for the release, to push the container on your ACS. In Releases, click on + then choose Empty and finally, click on Next:

Visual Studio Team Services Create release definition

Your release definition will look like this:

Visual Studio Team Services Create release definition build

We will now create the artifact. In your release, click on Artifacts > Link an artifact source and provide another name. Click on Link:

Visual Studio Team Services Link an artifact source

Move it as Primary:

Visual Studio Team Services Releases artifacts

Now, click on Triggers and check the box Continuous Deployment, then select the new artifact that you created previously:

Visual Studio Team Services Release definition release triggers

Save. Click on Add tasks in Environments in your new release, then add an SSH task with the following command and uncheck the case Fail on STDERR:

The command will connect to the registry, download the image and deploy it if it doesn’t exist, or replace it if existing, with the last published version:

Visual Studio Team Services release definition environments

You need to add 3 variables:

  • username: contains the username to connect to the registry
  • password: contains the password associated with the user to connect to the registry
  • registry: contains the URL to connect to the registry

Visual Studio Team Services Release definitions variable groups

Don’t forget to save 🙂

We can now test our configuration. To start, modify your source code, and send it to GitHub. After few seconds, on your VM where the VSTS agent is running, you can see this:

source code to GitHub

And from the VSTS console, I can see that the Build step has been completed correctly:

Visual Studio Team Services Build succeeded

Same as the release:

Visual Studio Team Services All release definitions summary

And if I try to access to the URL that redistributes to Docker agents, I have this:

URL redistributed to Docker agents

I’ll now modify my index.html file, and send it on Github. From the VSTS agent, you can see this:

index.html file VSTS agent view

And from VSTS console, a new build, 35 (versus 34 before), is available:

VSTS console new build

And the release:

VSTS console all definitions summary release

The view from my WebApp:

Azure web application view

And in the movie:


To conclude, this new method will delight your developers but also admins.

Developers because they will be autonomous, and will just have to push their code changes on a Git to be able to deploy it into production.

And from the admin side, finished the repetitive tasks that are not always the most interesting 🙂

Views All Time
Views Today
Appreciate how useful this article was to you?
No Ratings Yet
Back to blog
The following two tabs change content below.
Florent Appointaire
Florent Appointaire is Microsoft Engineer with 5 years of experience, specialized in Cloud Technologies (Public/Hybrid/Private). He is a freelance consultant in Belgium from the beginning of 2017. He is MVP Cloud and Datacentre Management. He is MCSE Private Cloud and Hyper-V certified. His favorite products are SCVMM, SCOM, Windows Azure pack/Azure Stack and Microsoft Azure.
Latest posts by Florent Appointaire (see all)