Do you remember reading about new features added to Facebook, Twitter, etc. but only a few users have been able to prove or see them? Moreover, it may happen that these new features don’t be available for other users or otherwise be released at a general level in a matter of days or weeks. This is a practice that companies use to test visual or functional changes in their applications, in order to know if they are accepted by its users, capture new use cases and so on.

If you work with Microsoft Azure Web Sites, we have a tool through the new portal called Testing in production, which allows us this behavior: defining percentages of the production traffic to refer to experimental environments or other use you decide.

Configuration

Access the new portal through
<href=»https://portal.azure.com/» title=»https://portal.azure.com/» https://portal.azure.com/ and select your website from Browse > [Filter by] Websites. At the bottom of the site information, we see that there is a section called Testing in production which tells us that all traffic is being served through the production slot:

The first thing that we noticed is that must have a Standard plan before creating a new slot:

To modify the plan, just go to the Pricing tier section and select the Standard model that best fits your needs:

Once updated the Web Hosting plan, we create a new slot. In this example I called new-facelift, because I would like some of my traffic try a different environment with some visual changes of my website:

For this example it is enough to show the default content when a new web site or slot is created in order to check the Testing in production feature.

The last step is to define how much of traffic we want to serve via the new slot and how much production will be served by itself. To do this, select the generated slot and apply the percentage:

Save the changes and try it in two different browsers to access the URL of production:

In the picture above you can see that each browser is accessing the same URL but with different results.

If we want to find, or modify, in which environment the user must have affinity for the use of the application we can access to the developer tools and access the section that handles cookies. In it we can see that we have a cookie named TiPMix, which contains the percentage related with the slot where you are working on. In this example, if the percentage is less than 50% requests will be handled by the new slot and, if not, the rest will be handled by the production environment:

If we remove the cookie, a new percentage will be assigned.

Hope this helps.

Happy testing in production! 🙂