Using routing rules to validate a site before go live/swap (DXC Service)
During a deployment in DXC Service a temporary slot is created where the new version of the site is pushed, prepared and warmed up. If everything looks good during the manual validation step, it will finally be swapped with the previous version of the web app.
The new version of the site is usually accessible via the following link:
https://{webappname}-slot.dxcloud.episerver.net/
The recommendation is to have a default site with a "*" binding or at least add the hostname above in the site bindings of the CMS (see "Before going live") to make this URL work, but what if you need to validate more sites before you feel comfortable swapping the deployment slot? Or if this binding just isn't added for some reason?
Consider the following setup as an example:
When trying to browse this site through the slot-address mentioned above, it would just respond with a 404 like this:
Some implementations might also expect certain host headers to be used which could make validation of the slot quite tricky.
This is where routing rules can help!
So what are routing rules? How can I use them?
Routing rules is a Azure feature that makes it possible to route traffic via one of the hostnames assigned to the web app to one of its slots. During DXC Service deployments, the deployment engine will automatically attempt to configure routing rules for the slot so that any of the assigned hostnames can be tested in the slot, this is done just before the "warmup step" in the deployment. Before the slot is swapped (the complete/go live step), these rules are removed again. The rule is configured so that no production traffic is routed to the slot (100% to "production slot" and 0% to the deployment slot) while still allowing the routing rule to be used if a special cookie is added.
Using a cookie to browse the slot using a custom hostname
While there are actually two ways of triggering this behavior, using a cookie is the most reliable way. You simply need to add a cookie named "x-ms-routing-name" to your browser session with the value of the slot you want to browse (which for DXC Service deployments will be "slot").
The following example shows how it can be achieved in Chrome:
- Browse the hostname you want to use, for example www.alloytech.biz (you might want to use "incognito"/"private"-mode to avoid having this cookie stored in your normal session after you've validated the slot, or make sure you remember to remove it)
- Press F12, go the the "Application"-tab and expand "Cookies on the left hand side:
- Double-click under the last cookie in the list and enter "x-ms-routing-name" as the cookie name:
- Enter the slotname in the "value" field for the new cookie, for DXC Service deployments, the name should simply be "slot":
- Press Enter, and refresh the page and you will be browsing the slot using the hostname you entered in step 1!
It is also possible to use a query string to trigger this behavior, you simply add "?x-ms-routing-name=slot" to the address, however, this method isn't as reliable since requests issued by scripts on the site could still be routed to the "production slot", so it's recommended to use the "cookie method" instead.
How are routing rules used during deployments then?
During deployments in DXC Service, routing rules are used to check the status of the warmup process, the deployment engine will look for a hostname to use in the application initialization-section of Web.config.
If you want to check what hostname was used to validate the slot during the deployment you can check the deployment output log, after each site in the deployment has been warmed up the results are posted to the log which includes a "ManualValidationLink":
This link can be used directly in the browser, but since the cookie method is more reliable, it's recommended to use that instead (but you could of course still find and copy the cookie name and value from this link!)
Comments