Continuous Deployment with VSTS/TFS and App Service Environment (ASE)

My colleague Harshal Dharia and I have been exploring workflows for CI/CD using VSTS or TFS when using Azure App Service Environment (ASE). In this blog post, I provide some templates to illustrate this workflow.

The Azure App Service Environment (ASE) allows you to deploy Azure Web Apps into a private environment for enhanced security and access control. One challenge with this configuration is how to orchestrate Continuous Integration and Continuous Deployment (CI/CD) with Visual Studio Team Services (VSTS) or Team Foundation Server (TFS) into such environments. If you are unfamiliar with VSTS and CI/CD pipelines to Azure Web Apps, please see the VSTS Documentation and Tutorials for more details.

It is possible to let the Web Applications pull the application in from DropBox, etc., but that makes it a little less elegant to use VSTS/TFS for CI/CD. The solution to this problem is to deploy a VSTS/TFS build agent into the Virtual Network where the ASE is deployed and let that agent do the deployment. The VSTS/TFS agent does not need to be accessible from the internet. If you are using VSTS, the agent needs only outbound access to connect to VSTS. If you are using TFS deployed in a Virtual Network as described in a couple of my previous blog posts here (simple deployment)  and here (high-availability deployment), the agent can be completely isolated.

The proposed configuration looks like this:

When configuring the agent, it needs to know the DNS configuration of the Web App it is to deploy to. Since the private resources in the Virtual Network don't have entries in Azure DNS, you need to add the information to the hosts file on the agent machine. I have made a template for deploying the agent into the Virtual Network. The agent is configured with this Powershell DSC script; feel free to grab it and modify for your scenario. The template requires URL information for the VSTS/TFS instance and you need to have an Agent Pool and PA Token ready to allow the agent to join. Note, this template is only for deploying the agent, it assumes you have an ASE set up already.

I have also created an ASE DevOps template that deploys the complete scenario (including ASE and JumpBox) illustrated above. This template will take a while (on the order of one hour) to deploy, since deploying an ASE takes some time. The template requires a number of parameters (including a string blob for the SSL certificate). The repository includes a convenience script that will help you assemble the necessary components. It will also generate a self-signed certificate for your domain if you do not provide one. To use the script, issues a command like:

.\scripts\PrepareAseDeployment.ps1 -DomainName `
-TSServerUrl "https://<VSTSPROJECT>" -AdminUsername EnterpriseAdmin`
-AgentPool <NAME OF POOL> -PAToken <PA Token for VSTS/TFS> `
-OutFile C:\temp\myase-devops.parameters.json

When the deployment is complete, you should be able to log into your VSTS or TFS instance and see that the build agent is registered in the agent pool:

You can then configure a Deployment Configuration that uses the associated agent pool:

If you have used a self-signed certificate for the ASE configuration, you will need to set the option "-allowUntrusted" for MSDeploy:

It is also recommended to set the variable VSTS_ARM_REST_IGNORE_SSL_ERRORS to true. If you have deployed your ASE with appropriate certificated from a certificate authority, this should not be necessary.

And that is it. Let me know if you have questions/comments/suggestions or you run into problems deploying.