Windows Azure Staging Model

One of my favorite features of Windows Azure is their Production/Staging model.  I think the best way to explain why I think this is so well implemented is to walk you through the processes.

Here we have Test1 running in Production and Test2 running in Staging.  Clients that go to your production URL are routed to your production code.  Clients that go to your staging URL are routed to your staging code.  This allows you to have your customers use your production code, while you can test your new code running in staging.


Now that I’ve tested my staging code I am ready to move it to production.  I click the swap button located in-between my two versions and Test2 becomes production and Test1 is moved to staging.  What happens behind the scenes is the load balancer (managed by the Azure platform) starts directing incoming requests to your production URL to servers running the Test2 code base and requests coming into your staging URL are routed to servers running the Test1 code base.  This process literally takes a few seconds since the Test2 code base is already running on servers.  This also gives you the advantage of being able to immediately switch back to your old code base if something goes wrong.


Now we have updated our code again and have pushed up Test3 to our staging area.  We now have Test2 still running in production, and can do testing on Test3 in staging.


Now that we have tested our Test3 code and are ready to move it to production we hit the swap button again and Test3 becomes production and Test2 is moved to staging ready to be moved back into production on a moments notice.


One thing to take note of is that the Web Site URL’s for Production and Staging never changed.  Unfortunately neither of them are URL’s you want your customers to see or you would want work with.  What you want to do is create to DNS CNAME records.  In the example case I’m using here you would create two DNS records:    CNAME     CNAME