Deployment Slots

Question 1

What tiers support deployment slots?

Answer 1

• standard, premium and isolated
• different pricing tiers support different number of slots
• to scale to different plans make sure the plan has the same or a greater number of of slots, cant downgrade if using more slots than allowed on tier below

Question 2

What are deployment slots

Answer 2

• Separate deployment areas that contain live apps with their own host names

Question 3

What are the benefits of deployment slots?

Answer 3

• allows you to validate changes in a staging slot before swapping to a prod slot
• deploying an app to a slot first and swapping into production makes sure all instances of the slot are warmed up, eliminating downtime as traffic redirection is seamless and no requests are dropped
• post swap the slot with previously staged app now has the production app, can easily swap back

Question 4

What is the first step slots take to eliminate downtime?

Answer 4

• Apply the following settings from the target slot (e.g. prod) to all instances of the source slot
• slot specific app settings and conn strings
• Continuous deployment settings if enabled
• App Service auth settings if enabled

Question 5

What is the second step slots take to eliminate downtime?

Answer 5

• wait for every instance in the source slot to complete its restart
• if any of them fail the swap operation reverts all changes to the source slot and stop the operation

Question 6

What is the third step slots take to eliminate downtime?

Answer 6

• if local cahce is enabled with custom warm up, trigger app initiation by making a HTTP request to the app root on each instance of the source slot
• if ‘applicationinitialisation’ isn’t specified, trigger an HTTP request to the app root of the source slot on each instance
• if an instance returns any HTTP response is considered warmed up

Question 7

What are the fourth and firth steps slots take to eliminate downtime?

Answer 7

• Once all instances are warmed up, swap the slots by switching the routing rules
• Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting instances
• Target slot remains online while the source slot is being prepared regardless of success or failure

Question 8

What is best practice when swapping web apps?

Answer 8

• Ensure the prod slot is always the target slot
• this way the swap operation doesn’t affect prod apps

Question 9

How can we make settings swapable between slots?

Answer 9

• Add the app setting “WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICK_SLOT_SETTINGS” in every slot and make its value 0/false

Question 10

What is the ‘swap with preview’ option?

Answer 10

• The swap operation is paused for you to validate that the source slot works with the target slot settings
• source slot is warmed up before slot completion which is good for mission-critical apps
• performs same swap operation as usual but pauses after the first step, allowing you to verify results before continuing

Question 11

What is auto swap?

Answer 11

• whenever you push code changes to the slot, app service automatically swaps the app into production after its warmed up in the source slot
• not supported on linux and web app for containers

Question 12

How can we configure a custom warm up?

Answer 12

• add the ‘applicationintialisation’ config element in web.config
• swap operation waits for this custom warm-up to finish before swapping

Question 13

What is the acitivity log?

Answer 13

• Shown on the apps resource page in the portal
• highlights information regarding a swap and appears in the logs as ‘swap web app slots’

Question 14

How does routing work with slots?

Answer 14

• by default all traffic routed to prod slot
• you can route a % of traffic to another slot
• useful if you need user feedback for a new update but you’re not ready to release it to prod

Question 15

How do we route traffic automatically with deployment slots?

Answer 15

• In the traffic % column of the slot you want to route to specify a % and click save
• the specified % is then randomly routed to the non-production slot
• A user that’s routed is pinned to that slot for the life of that client session

Question 16

How can a user tell what slot they are running on?

Answer 16

• Look at the x-ms-routing-name cookie in your HTTP headers
• production slot is x-ms-routing-name=self
• staging is the same but with =staging instead

Question 17

How can we route traffic manually with slots?

Answer 17

• Useful when you want your users to be able to opt in to or out of your beta app
• use the x-ms-routing-name query param
• e.g. a button with a href=’<webappname>.azurewebsites.net/?x-ms-routing-name=self' will take users back to production slot and every subsequent request has that cookie that pins the session to production</webappname>

Question 18

What are examples of some setting that are swapped between slots?

Answer 18

• General settings such as framework version, 32/64 bit, web sockets
• app settings (can also be configured not to)
• conn strings (can be configured not to)
• handler mappings
• webjob connect

Question 19

What are examples of some settings that are not swapped between slots?

Answer 19

• publishing endpoints
• custom domain names
• scale settings
• webjob schedulers
• IP restrictions