a basic Azure Web App website was built and deployed using
illustrated how additional files could be included when building a web project.
could be added to the
Load Testing was added to the build pipeline. This post will explore adding slots to help
the build process and limit downtime.
A powerful feature that Azure Web Apps provides is the ability to use slots. A slot can be viewed as another instance of the website and can enhance the build pipeline by providing a convenient way to limit downtime and disruption by allowing the changes to be verified before making the changes
as well as ensuring the website has been warmed up. Another benefit of using slots is the ability to swap back to a previous deployment if a fault is detected after the site been released.
In our example pipeline, we will define the slot and use our defined load tests to verify the site before performing the swap.
Updating the build pipeline to deploy to the new staging slot can be specified in the Deploy AzureRM Web App step as follows:
The change will then deploy the website to the new slot but our load testing will still be pointing to the main web app and not the staging slot. There are many ways to update the load test to handle this. The simplest would be to update the webtest to instead point to the staging slot url. The second takes a bit more effort but provides the benefit of being able to use the same webtest against multiple websites. This involves promoting the webtest url as a parameter and setting this in our load test definition.
The first step is to parameterize the web servers which detects the called web servers and creates corresponding context parameters. In the image below I renamed the generated context parameter to
The following shows the webapp parameter in the webtest file. Note how all the urls have been parameterized:
The next step requires adding a new context parameter to the load test.
Note: in more complex load tests, some care is required when naming the parameters to avoid name collision when referencing multiple webtests in a single load test unless this was the intention. For example, a single parameter for the url to be tested that is defined in all webtest definitions.
As the test project is part of our codebase, a check-in of the latest changes will cause a new build with the parameterized load test.
Our build pipeline now deploys to a staging slot and in order to make the changes visible on the main url, a swap is required. After reviewing the staging website, this can be done manually by using Swap on the App Service.
In summary, the build pipeline has been set to continuously deliver changes to a staging website including running necessary Gulp tasks and unit tests. The deployment has been validated using VSTS Load Testing.
Hopefully this provides a helpful introduction to different aspects of the build process and how they can be pulled together to provide a consistent and more reliable approach to software delivery. There are many tasks and aspects that were not covered so please comment if there is a particular feature or item that you would like to be covered or expanded upon. Also please post any references to sources that provide more detail to VSTS Build.