Integrating On-Premises Jenkins with VSTS to deploy to an ILB ASE


I recently had to work on integrating an on-premises Jenkins with VSTS in order to use VSTS’s out of the box capabilities to deploy resources to Azure. Although there is quite a good documentation on this topic, you must be able to read between the lines. So, with this blog post, I’m not going to repeat was is described in the article but I’m going to try to fill the gap when it comes to integrating with an on-premises Jenkins and not with a Cloud-based Jenkins, as assumed by the Microsoft documentation. Since an image tells more than a lengthy speech, here is one that sum it up all:


So, in the big lines, the combination of blue & red lines allow for a full Continuous Deployment Story, meaning that whenever something happens at Jenkins level, a VSTS release definition is triggered automatically to deploy resources to Azure. In this schema, this is an ILB ASE. It’s important because it’s not publicly accessible.

Here, I’m using a self-hosted VSTS agent that is in the same VNET as the ILB ASE and that has connectivity towards the on-premises Jenkins Server through expressroute but this could be S2S VPN as well. The VSTS agent is using HTTPS outbound to connect to VSTS with PAT (Personal Access Token) kind of authentication. The agent connects through HTTP or HTTPS + FBA, depending on your Jenkins setup. The default installation is merely HTTP+FBA but Jenkins can deal with different kind of authentication mechanisms as well as using HTTPS instead of HTTP.

Now, if we zoom on the red lines only, we see that the on-premises Jenkins server URL must be published through a reverse-proxy as an external facing URL. This is required for VSTS Service Hooks that are used to enable CD and trigger releases automatically.

Bottom line: if you can afford to trigger VSTS releases manually (or schedule) them, you can forget the red lines.

There is still an extra trick you need to know if you go for the blue lines only, meaning not publishing an external URL for the Jenkins server. When creating your Jenkins Service Endpoint is VSTS, do not try to test it as it won’t work:


It won’t work simply because the URL is an on-prem one and VSTS has no way to connect to it. However, you can safely register the endpoint. The trick comes later on when setting up the release definition, make sure to use Jenkins tasks to download the artifacts and do not try to use the release artifcats feature as this one only works with external facing endpoints:



This will make sure artifacts are downloaded by the task executed by your self-hosted agent that has connectivity to your on-premises Jenkins server.

Happy deployments!




About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure, DevOps, vsts and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s