Sep 30, 2015 Azure Web App deployment slots are used to help roll out new versions of an app without downtime or cold start activation. New version is typically deployed to a staging slot, then after testing and final verification it gets swapped into a production slot. During the swap operation the Web App’s worker process may get Continue reading 'How to warm up Azure Web App during deployment.
-->Consider you have an Azure App Service Web App that handles a large amount of traffic and accesses a database, with an architecture similar to that shown in Figure 1. When you make a deployment you would not want to take the risk of deploying bugs or having significant downtime when you deploy a new release, this is what you would want to have a Deployment Slot. A deployment slot is an additional Azure App Service Web App instance (W3WP) which is ~bound to your production Azure App Service Web App of the same name and runs on the same App Service Plan (ASP) that I discuss here. This development slot lets you deploy you test or non-production ready code for testing prior to the release to the live Web App. The beauty of the deployment slot is that you can slick a button and the deployment slot which contains the new version is swapped with the production, and bang, the new version is live, with just a click.
Notice in Figure 1 there is a SQL Server which has 2 SQL Azure databases on it, one called stickyslot-pro and the other stickyslot-tst. Additionally, there is an App Service Plan (ASP) called STICKYSLOT-ASP that runs an Azure App Service Web App called stickyslot with a deployment slot named testing. All of which are contained within a Resource Group called STICKSLOT-RG.
Figure 1, best case, App Service architecture diagramHere is a very good article that discusses sticky slots.
In this article I am concerned with the swapping of the Azure App Service Web App deployment slots from PRO (production) to TST (a testing instances). The thing is, by default, App Settings and database connection strings are NOT sticky to the slot and will follow the Web App when the test slot is swapped with the production slot. In this scenario, it means that when I swap my testing deployment slot, which is, by the way, getting its data from the stickslot-tst database, to production, the then swapped Web App will be pointing to the stickyslot-tst database instead of the stickyslot-pro database. Therefore, I need a way to swap the Web App development slots but keep the database connection string of the current production Web App pointing to production and the testing pointing to the testing database. This is achieved by making the setting ‘sticky to the slot’.
Assume that for my production Web App, I have 2 values I want to remain ‘production’ when I perform a swap. See Figure 2.
Figure 2, sticky slot settings that remain in production even when swapped with a testing slot
Notice there is a App setting with the name STICKSLOT with a Value = ProductionEnvironment and a Connection string called StickySlotConnectionString that contains the production database name, user is and password, for example. Most importantly, notice that the Slot setting check box is selected which means that is remains with this Web App and is not moved when swapped. Notice also that in the testing development slot, see Figure 3, I have the same App Setting and Connection string (Key and Name), but they have different values, also with the Slot setting checkbox checked so it remains on the testing Web App, no way do I want my testing Web App to ever point to the production environment.
Figure 3, sticky slot settings that remain in testing even when swapped with a production slot
I have added an additional App setting, MoveWhenSwapped, which I have not made sticky, I.e. this one will move with the swap. Therefore, when I swap production and test, then that App setting will be in the production Web App configuration and not in the testing one. Let’s see, when everything is all tested and ready for production on the testing environment, navigate to the testing Web App and click the Swap link, as shown in Figure 4.
Figure 4, swap Azure App Service Web App between slots, sticky slots
There is a feature called “swap with preview” which has a nice write here. Basically, this feature let’s you point your testing environment to production just to make sure everything is working as expected before you begin to route the real traffic. Make sure you either complete the swap or roll it back as you wouldn’t want to keep your testing pointing to production for very log. This may not work in all scenarios if there is a database structure change which may break the production environment if deployed and the testing instance doesn’t run on the exiting production database without upgrade. However, give it s shot JIC. Nonetheless, make the swap and then check the production Web App to confirm the App Settings and the Connection string are the expected result. Indeed they are as show in Figure 5.
Figure 5, sticky slots Azure App Service Web App App Settings and Connection strings
The values remained as expected and the MoveWhenSwapped moved from the testing to the production Web App process. Also note that the MoveWhenSwapped moved, which means it no longer exists on the testing Web App. This means, if you want to swap your Web App and want the connection string to remain as is, then mark the setting as sticky by selecting the Slot setting check box and you are all set.
Some questions I had:
- How do I access Connection string and App Settings from my code
- What happens if I have a connection string in my web.config file and what happens if I have both
Let’s answer those questions.
To access the connection string from either the value configured in the portal or in the web.config you use the following code.
Pass the name of the connection string and the value is returned.
To access the app setting value, use the following.
Nothing really, as long as the name is unique. Watch out that you do not have the same name for any connection string or app setting. If this happens, then, when I tested it, the values configured in the portal were the values accessed by the code. Therefore, if you have a connection string called StickySlotConnectionString configured in both the portal and a web.config, then changes you make to the value in the web.config will be ignored.
Azure Cloud Service Staging Slot Url
-->Cloud Service Pricing
Choosing Azure App Services to host a web application means that you are using a managed platform and therefore have less responsibilities (such as OS updates and patching). Another specific feature that can be extremely useful is slots. Slots allow you to deploy your application to a separate live app service, warm it up and make sure it’s ready for use in production, and then swap the slots to provide seamless traffic redirection.
Azure Cloud Service Staging Slot Software
You can slot swap manually (in the portal or command line) or you can automate the slot swap with Auto-swap or in a script.
I’ve been asked a few times recently about how to do this as part of a VSTS release pipeline and so I thought I’d outline my approach here.
Scenario
Let’s keep it pretty simple and say that the release pipeline for a web application is going to cover deploying to a Dev environment, then QA, then Staging and finally Production. Human approvals will be needed at points, but especially in approving the final release into Production. We will use slots so that the staging environment can be warmed-up, reviewed and then final approval triggers the slot swap.
VSTS Release Pipeline
We’ll create a release pipeline that has Dev, QA and Production:
Why no Staging? The Production environment will have both a staging and production slot and we’ll manage the transition between the two in that environment.
Why are Dev and QA separated? To reflect the app service separation. You could have Dev and QA as additional slots in production (you can have up to 15) but it makes sense to keep the production and non-production environments apart. This allows you to choose different hosting plans (size/scaling/cost) and also isolates impact, such as load testing in the QA environment.
Could you have Dev and Test as separate slots in a single “non-production” environment? Yes, you could. I’ve chosen to split them so they have potentially different lifecycles but that’s more subjective.
Configuring slot swaps in Production
The Dev and QA environments orchestrate whatever flow you want in those environments (e.g. provision using ARM, deploy, run functional tests, run load tests etc.), and in this example don’t have any slot specific activity. Therefore let’s take a look at the production environment tasks:
(I’ve kept this to a minimum to keep it clearer, so no provisioning, running scripts or other activities.)
Azure Cloud Service Staging Slot Free
First deploy the web application to the staging slot in the production environment using the Azure App Service Deploy task:
Check the Deploy to slot option in the standard task, and then choose the Slot (I called the slot “staging” but you can use any name).
Staging Slots Azure
Next I’ve added an Agentless phase as it’s not going to delegate any actions to an agent, and added a Manual Intervention task. This causes the flow to pause until the manual intervention is completed by the specified approvers (groups and/or individuals). If it’s approved then it carries on, if it’s rejected (or times out and therefore is rejected) then the flow stops. In this case that works for me as I want the staging environment to be manually verified and then signed off as ok for final release to production. If it gets rejected then it never gets promoted from staging to production.
Finally, if the staging slot has been manually verified and is ready to be used, then we can initiate the actual slot swap (in an agent phase) using the Azure App Service Manage task:
Azure Web App Staging Slot
The staging and production slots will then be swapped over, leaving the old production version in the staging app and the latest version in the production slot.
Cloud Service Azure
This flow supports the actual slot swaps being automated, but with manual approval. A nice side effect of the slot swap is that should there be a problem, the slot swap can be reversed to redeploy (rollback) the old version of the app now in the staging slot.