DevOps with VSTS - The First Way: Continuous Delivery

Posted on Thursday, January 26, 2017

This is part 3 of the DevOps with VSTS series

Continuous Delivery is the automation of creating and updating environments and deploying a release package into an environment.
Automating this step enables us to reduce handovers and eliminate bottlenecks and therefor is a major improvement of the lead time for any new functionality or change.
Furthermore, by automating creating and updating environments, infrastructure is treated as code and thus has all the benefits from source control as well.
By having infrastructure as code, the creation of new environments is also simplified and it is ensured that all environments are consistent with each other.

Setting up a Continuous Delivery in VSTS is also not to much work.
This post will show how to set up the following items:

  1. Deployment Project
  2. Release Definition
  3. Dashboard

Deployment Project

The infrastructure for the sample project that is being used in this post is a fairly simple one, it consists of an Azure App Service and an Azure Storage Account.
The creation of infrastructure in Azure can be easily automated by using Azure Resource Manager templates.
Visual Studio has great support for a lot of Azure features and the usage of ARM templates is no exception.

First let's start with adding a new Azure Resource Group project to the solution that will be used for the ARM template.

The next step is to select a pre-defined template that resembles the infrastructure the project uses.
I've selected the Web app template. After the project has been created, I modified the ARM template (WebSite.json and WebSite.parameters.json) so they also include the Storage Account.
This modified template can be found in the sample project on GitHub

With the ARM template done, it is time to commit it into source control.
Because the Continuous Integration is already set up, the changes need to be committed using the correct flow.
Since setting up Continuous Delivery is also work and all work should be made visible, create a User Story in VSTS representing the work being done.
After that commit the changes to a new remote branch in Visual Studio and then create a new Pull Request in VSTS under Code => Pull Requests.

Don't forget to link the User Story to the PR otherwise the PR can not be completed.

Release Definition

With the infrastructure commit as code, it is now time to set up the actual Release Definition.
In VSTS browse to Releases under Build & Releases => Releases and select New definition.

In the next step select the Azure App Service Deployment template and in the next page enable Continuous deployment.

When the Release Definition has been created, there are still a few settings to be done.

  • Select the correct Azure Subscription
  • For App Service name enter $(ApplicationName)
    • $(ApplicationName) is a VSTS Environment variable which will be specified in one of the next steps.
  • For Package or Folder click the ellipsis button and browse to the release package.

With this done, a new release package can be deployed. But the infrastructure should also be created.
To do this add an Azure Resource Group Deployment task and drag it before the Deploy Azure App Service task so it is executed first.

The settings that need to be modified for this task are:

  • For Resource Group enter $(ApplicationName)
  • For Location enter $(ApplicationLocation)
    • $(ApplicationLocation) is also a VSTS Environment variable which will be specified in one of the next steps.
  • For Template click the ellipsis button and browse to the ARM template WebSite.json.
  • For Template Parameters click the ellipsis button and browse to the ARM parameters file WebSite.parameters.json.
  • For Override template parameters enter -ida_ClientId $(ida_ClientId) -ida_ClientSecret $(ida_ClientSecret) -ida_Domain $(ida_Domain) -ida_TenantId $(ida_TenantId)
    • These parameters are appSettings used in the WebSite project. By setting these appSettings using the ASRM template and overriding them with Environment variables, there is no need to commit Environment specific settings in source control or to manually change these settings in the Azure Portal. Fully automated so an improvement in lead time.

The last step is to make sure all settings have correct values for this environment.
To do this select the ellipsis button on the environment and select Configure variables.
Enter all the correct values and after that trigger a release to see if everything is working correctly.

With this Development environment set up, it is very easy to add a new environment to the deployment pipeline.
Simple select the ellipsis button on the environment and select Clone environment.
Change all the environment variables and you are good to go.

To fully optimize the Deployment pipeline you want to add some Integration and Load testing tasks right after the Deploy Azure App Service task. This way you can ensure that an environment is working as expected and catch any integration bugs.

Dashboard

It is very convenient to have a good overview of the status of all releases to different environments.
VSTS has another set of nice widgets that does this for us.
In the dashboard add the widgets Deployment status and Release Definition overview.
With these two widgets you can see instantly what the status of the releases is.

With Continuous Delivery completely set up, the next thing is to set up a Kanban board to track all the work.
How this can be done in VSTS, is shown in the next post Kanban


Disclaimer: Any views or opinions expressed on this blog are my own personal ones and do not represent my employer in any way.