November Happy Hour will be moved to Thursday December 5th.

Anders Wahlqvist
Mar 26, 2019
  11468
(8 votes)

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:

  1. 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)

  2. Press F12, go the the "Application"-tab and expand "Cookies on the left hand side:


  3. Double-click under the last cookie in the list and enter "x-ms-routing-name" as the cookie name:


  4. Enter the slotname in the "value" field for the new cookie, for DXC Service deployments, the name should simply be "slot":


  5. 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!)

Mar 26, 2019

Comments

Matthew Boniface
Matthew Boniface May 9, 2019 06:47 AM

This is awesome, thanks Anders!

Tahir Naveed
Tahir Naveed Jun 10, 2019 03:12 PM

Good share. Thanks for sharing. 

Anders Wahlqvist
Anders Wahlqvist Jun 11, 2019 02:26 PM

Thanks for reading! Glad you find it useful! @Matthew @Tahir

Darren Sunderland
Darren Sunderland Nov 7, 2019 10:14 AM

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.

Anders Wahlqvist
Anders Wahlqvist Nov 7, 2019 01:13 PM

Glad to hear that @Darren, that's a great use case for this feature!

Drew Douglas
Drew Douglas Jan 27, 2020 08:42 PM

@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?

Anders Wahlqvist
Anders Wahlqvist Jan 28, 2020 07:50 AM

@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).

Kristian Adrup
Kristian Adrup Mar 17, 2021 10:01 PM

@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.

Kristian Adrup
Kristian Adrup Mar 18, 2021 12:15 AM

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.

Anders Wahlqvist
Anders Wahlqvist Mar 18, 2021 08:02 AM

@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.

Please login to comment.
Latest blogs
AsyncHelper can be considered harmful

.NET developers have been in the transition to move from synchronous APIs to asynchronous API. That was boosted a lot by await/async keyword of C#...

Quan Mai | Dec 4, 2024 | Syndicated blog

The search for dictionary key

Recently I helped to chase down a ghost (and you might be surprised to know that I, for most part, spend hours to be a ghostbuster, it could be fun...

Quan Mai | Dec 4, 2024 | Syndicated blog

Shared optimizely cart between non-optimizley front end site

E-commerce ecosystems often demand a seamless shopping experience where users can shop across multiple sites using a single cart. Sharing a cart...

PuneetGarg | Dec 3, 2024

CMS Core 12.22.0 delisted from Nuget feed

We have decided to delist version 12.22.0 of the CMS Core packages from our Nuget feed, following the discovery of a bug that affects rendering of...

Magnus Rahl | Dec 3, 2024

Force Login to Optimizely DXP Environments using an Authorization Filter

When working with sites deployed to the Optimizely DXP, you may want to restrict access to the site in a particular environment to only authenticat...

Chris Sharp | Dec 2, 2024 | Syndicated blog

Video Guides: Image Generation Features in Optimizely

The AI Assistant for Optimizely now integrates seamlessly with Recraft AI, providing advanced image generation capabilities directly within your...

Luc Gosso (MVP) | Dec 1, 2024 | Syndicated blog