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!)
This is awesome, thanks Anders!
Good share. Thanks for sharing.
Thanks for reading! Glad you find it useful! @Matthew @Tahir
This was really helpful when implementing automated testing in a CI/CD pipeline, for a multi-site solution. It enables me to validate all sites and provide greater confidence to all of our different stakeholders.
Glad to hear that @Darren, that's a great use case for this feature!
@Anders
Looks like it's using a modified domain in my log, now, withouth the query string:
https://<webAppName>-slot.dxcloud.episerver.net/
Is this valid only after warmup, or during all of deployment, or can I use this any time to hit the slot site?
@Drew That is the default hostname we assign to the deployment slot, so it's fine to use that, it's always there. We will however stop the slots when deployments are done so it won't be that useful outside of a deployment's warmup phase (that's when the slot is started).
@Anders you write that the routing rule is removed just before swap, but that doesn't seem to be the case as I continue to get x-ms-routing-name and TiPMix cookies set from the site. I'm trying to get the most out of the China CDN by caching markup and these cookies are affecting my hit ratio negatively since Cloudflare don't want to cache something with a set-cookie. Like you say the slot is stopped after swap, so there's no point in keeping the routing rule around. Any help on this would be appreciated.
Hello again! After looking att more sites, I see that only about a third of our DXP sites set these routing cookies. That seems promising. Hopefully you know what the issue is. They all use paasportal deployments if that matters.
@Kristian Adrup: That does sound a bit weird. We do cleanup the routing rules after each deploy so it's definitely not expected. The only thing I can currently think of is if a routing rule has been left there (potentially for another slot on the web app used during some migration job or something in the platform). Doesn't affect the web app per se but could explain why you still see these cookies. Could you send in a support ticket and mention my name in it and ask them to escalate it (could mention this blogpost as well)? Then I can get some environment information and investigate the root cause.