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:
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.
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.
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:
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.
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