Diving in to Azure App Service Continuous Delivery (Preview)

I was messing around in the new Azure Portal today and while doing some changes in an Azure Web App notices something new that has appeared out of nowhere in the Web App Menu. Folks we got a new and exciting feature for Azure App Service. That is Azure App Service Continuous Delivery (preview). As soon as I saw this I jumped in and see what is going on.

Basically, what this does is it sets up a complete Continuous Delivery pipeline for your project with just a few clicks and configurations. It creates a robust development pipeline for your application from building your application, running your unit tests, running load tests and deploying your app to staging slots and then to production. The Continuous Delivery pipeline also includes pre and post deployment approval steps that is automatic to begin with but customizable for your needs. As of now, you can set up your Continuous Delivery pipeline for Visual Studio Team Services hosted repository or a GitHub repository. I can only imagine that this would expand to other repository options that we had in normal App deployment. One caveat is that you need to have a Visual Studio Team Services account to create the delivery pipeline.

Guys, this is amazing, this is simply awesome. Recently I dived in to Azure ARM deployments and Created an entire Continuous Delivery pipeline from scratch by creating ARM templates for resources and then setting up the Build Definitions, hooking up the artifacts with a Release Definition to release the application in to appropriate environments with proper approval stages in place between deployments. It took some research and consumed some time to get this to a robust level. But guys, now you can do all of this, with few clicks within 10 minutes. How awesome is that?

Let’s dive in to how we can set this Continuous Delivery pipeline with this new Continuous Delivery (Preview) feature in Azure Portal. To complete this, you are going to need an Azure Subscription and a Visual Studio Team Services account. If you already have them, let’s get this party started.

Let’s start with Visual Studio Team Services repository. Later we will do the same thing with a GitHub Repository as well. To start I have created a Visual Studio Team Services Repository named “ContinuousDeliveryDemo” and then created a simple ASP.Net MVC 5 application. The app is pretty basic, it’s just the template we get when we create a MVC app in Visual Studio. Additionally, I added a unit test project for this. Then I committed the changes and pushed the newly added project to VSTS repository. Simple. I am not going to go through these steps, I assume you can do that already.

Let’s create a new resource group for our app in azure and start setting up Continuous Delivery. I’m gonna create a Resource Group with the name “ContinuousDeliveryDemo” to contain our App Services that we are about to create.

Then I’m going to create a Web App with App Services to host the sample app we created. I’m gonna call it “kvkcdvstsdemo”. Also when creating the Web App, I am creating a new App Service Plan with S1 Standard Pricing Tier. The service plan name is “ContinuousDeliveryDemoPlan”.

You have to have a S1 Standard Pricing Tier or above to create deployment slots so the deployment can happen in to staging slot before switching to production If you want to have Production Slots feature in Continuous Delivery (preview).

After the app is created, the next step is to setup Continuous Delivery with the, you guessed it.. Continuous Delivery (preview) feature in Azure App Service.

Go to your newly created resource group or to App Services section and click on the new Web App you created to access its configuration Options. If you are familiar with this blade, you should notice the new Menu item named “Continuous Delivery (Preview)” Highlighted with yellow, in the bellow image.

Click on this option and you will be taken to a blade with basic introduction in to Continuous Delivery (Preview) and a button to start configuring. Click on Configure button to start configuring the Continuous Delivery Pipeline.

Here you will see 4 steps to configure the pipeline. Setting up Source Code, Build, Test and Deployment. Let’s start with setting up out VSTS repository as the source code repository.

Setting Up Source Code

For Code repository, as of now you have 2 options, Visual Studio Team Service or GitHub. We are selecting Visual Studio Team Service. You need to select the VSTS account in the next option. This is where the build and release definitions are created and the whole pipeline is setup. After selecting the Visual Studio Team Service account, you can select the Project, Repository and the branch you want to deploy. My configuration looks like this. Yours will be different.

Setting Up Build

This step is really simple, you currently have 2 options as the Web Application Framework you can use. You have ASP.Net and ASP.Net Core as the options. Since we have ASP.Net app, we go with that.

Setting Up Tests

You have the option to setup load testing for your application. Your unit tests will run during the build step and after the build You can configure to have a Web App setup to run load tests before you deploy the application to Staging or Production. By default the NO is selected. I’m gonna select YES and do the configuration. You can use an existing application or you can create a new one. I’m selecting Create New since I don’t already have an application.

Surprisingly when you select Create New, you don’t have to do anything else, it will automatically populate the fields with an App Name, Select the Resource Group you are already using, Create a new App Service Plan and Select a default pricing tier for you. You just have to click Ok to accept the settings. Easy Right?

Setting Up Deployment

Next step is to setup deployment. By default this too is set to NO. To enable this, you have to have a S1 Standard Service Plan or higher associated with your Web Application (in our case the web app is kvkcdvstsdemo)

You have to option to select an existing Deployment Slot if your app already has one or, you can create a new one with a name, I’m gonna accept the default value and continue.

Now we are done. Click the OK button to accept all changes and it will create the Continuous Delivery Pipeline for you. After its done, you will be presented with a screen like this. It has links to created Build Definition, Release Definition, Triggered Build, Web App Slot, and Final Web app with the app deployed.

This has created a new Build and Release definitions for us and Kicked off a build for us. Clicking on the Build Definition Link will take you to Visual Studio Team Services and in to your ContinuousDeliveryDemo project and open the Build Definition overview page.

You can click the Edit button on the Top Right corner of the page to view the auto generated Build Definition. You can come in and customize this build definition to cater your needs later by adding more build steps or changing the current configuration.

Clicking on the Release Definition Link will take you to the overview page for the Release, it will show the created Release definition and you will see that the release has already being kicked off by the completed build.

If you open up the current release you can see that there are 2 environments automatically setup for you. They are Test and Production. Also, the app is release to both these environments one after the other.  You can open up the logs to see the steps involved.

You can see the highlighted Pre-Deployment approvals and Post Deployment Approval stages. You can later go in and edit these and setup to send email to specific approver to approve the build before and after deployment and continue to the next step or next deployment only if the approver approves it. This is very powerful and enable you with good visibility for your pipeline with specific approves approving the deployments.

If you go in to details about the Release Definition you can see the 2 environments Test and Production that is automatically setup by Azure. And for the test environment, apart from the deployment step a Quick Performance Test is also run on the deployed test environment. You can fiddle around and change the thresholds for the performance tests as well as add new Release Steps if you need any.

If you then go to Production environment, you can see the App deployment step and the final Deployment step Swap happening via a new Release Task. You can change things around here as well

Final Thoughts

There you go guys, awesome, isn’t it? Creating a proper Continuous Delivery Pipeline has never been so much easier with the new Continuous Delivery (preview) for Azure App Services.

This has some limitations in my view, when compared with the initial approach I had by Creating ARM templates for the resources we had and using a similar Delivery Pipeline where you have more flexibility in deploying to multiple environments and ability to configure the different environments more fluently with the use of templates and parameter files. But if later down the line you decide to create the ARM templates and use them to deploy, its just a matter of creating the Templates and parameter file and then swapping out the deployment task from the Release definition for the Azure Resource Manager deployment with the templates. Which takes way less time than creating the Templates and the Build Definitions, Release Definitions and the pipeline by yourself which is a huge plus point.

I just wish that I had this at the time I created the Delivery Pipeline for my projects, coz I would have certainly use this as the starting point and build on top of the auto generated Delivery Pipeline. But hey, now it’s finally here. And There is no excuse not to have a proper Continuous Delivery Pipeline for your projects.