This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles.
At this point, you have a CI/CD pipeline built on GitHub Actions that deploys your code into a staging slot whenever a commit is pushed to the main branch. In this article, you will learn how to release your new build to your production traffic by swapping the production and staging slots. You will also learn how to route a percentage of your production traffic to the staging environment to test the next build before it is fully released.
Swap the slots
Open the Azure Portal to your web app. On the left side menu, select Deployment slots. This will open a new blade showing a list of your site’s slots. You will see a production and staging slot. Click the Swap button at the top.
The Swap button will open a context menu with a table to preview any changes configuration changes that will occur after the swap. App settings are key-value configurations that are exposed to your app as environment variables. A future article will cover app settings in more detail. Click swap at the bottom of the menu to swap the slots.
When the operation completes, browse to the production site and you should see the sample application! The staging slot should now have the sample application, and the staging slot will have the placeholder HTML page with help text.
You can also use slots with custom containers.
Up to now, you have a GitHub repository that will trigger a GitHub Action workflow whenever there is a push to the main branch. The workflow builds and deploys the application to the staging slot of the site. You can use the staging site to validate your latest changes. When you’re ready, use the swap button (or CLI command) to swap the slots.
If you work in a large team, you can create slots for testing, quality assurance, canary testing, A/B testing, and more. Here is an example use case for multiple slots:
- Continuously deploy the master branch into a “testing” slot for developers to easily validate changes without pulling the branch and run it locally.
- Swap the build into a QA slot where the configuration more closely resembles the production slot. The new build is thoroughly tested by a QA or acceptance team.
- Swap into a staging slot where the build is tested against a fraction of the production traffic. The configuration here should match the production slot.
- Fully release the new build by swapping into the production slot.
There is an implicit distinction between deploying and releasing. For more information on this distinction, see this article.
Testing in Production
Testing in Production is the general practice of utilizing production traffic to test a new deployment before fully releasing it. This is an umbrella term for activities such as traffic shadowing, mirroring, or canarying. Traffic shadowing and mirroring are interesting topics, but they are outside the scope of this article. The remaining sections will explain how to canary your new deployments with App Service before releasing them to production.
In the Azure Portal, go to the Deployment Slots menu. In the table of your slots, you will see a column for Traffic %. By default, all your traffic is routed to the production slot. Try setting the traffic percentage to 10% on the staging slot. Then click Save. With that simple change, a tenth of your production traffic will now go to the new build! This practice is known as a “canary deployment” or “canarying a build”.
The term “canary deployment” originates from the “canary in a coal mine” idiom.
Now that some of your production traffic is routed to the new build, it is prudent to monitor the success of your deployment to catch errors, slow code paths, or other unforeseen issues. If you are using an application monitoring tool like Application Insights, Splunk, or Dynatrace, you will want to tag the metrics and logs coming from your staging slot so you can appropriately split the data in your reports and dashboards.
For your client-side code, the slot will expose a cookie,
with the slot’s name. You can retrieve this cookie and tag any outgoing metrics
or logs. In your monitoring service’s dashboard, you can filter or split the
data on this tag.
For server-side code, the slot will expose an environment variable,
WEBSITE_HOSTNAME, which contains the hostname and slot name. Much like the
client-side cookie, you can grab the value of the environment variable and tag
your logs or metrics.
You can manually route clients to a slot using the x-ms-routing-name query parameter.
Congratulations! Now you know how to release your latest deployments. You can also route a percentage of your production traffic to canary test the new build before fully releasing it. The next articles will cover certificates, domains, network security, and advanced configuration… so stay tuned for more!