Microsoft continues to deploy feature after feature with their Windows Azure service offering. Recently I happened upon their staged deployment feature, and it’s so handy.. I thought would write this post :)
So let’s start here. Go ahead and bing some information on what takes place when you deploy a website to Azure. I’m far from an expert on it, but Azure run’s through a number of processes to acquire a physical data host, generate the network mappings, deploy your application, and make it available. I’ve noticed that when I repeatedly deploy an application to the same Azure Website, the build process goes fairly quickly. My guess is that there are some comparison jobs going on, only deploying the necessary files. Either way, the issue I’ve run into is when I generate a new version of code on my “build machine”, and attempt to deploy. That’s where it takes several minutes.
All in all, it’s not terrible to wait that long, but it is limiting to when you promote to production if you know you can’t target a mid-day deployment because of this. Staged deployments make this much more palatable.
What is staged deployment?
Let’s start basic, what is staged deployment? With Azure Websites, you can take your Azure site, and “duplicate” it. When you do this, 2 things happen. One, you get a “-staged” version of your site (so if the regular site’s name was mywebsite.azurewebsites.net, a website is created called mywebsite-staged.azurewebsites.net). Secondly, these two sites are now “linked”, meaning you can swap deployments between them.
How is this helpful? With staged deployment, you can promote your production website, access the site to validate changes, and when the time comes, put it live. When pushing new content to the staging site, your current site doesn’t take a hit… it’s not even aware that website files are being affected. Heck, if needed, you can promote your new website build days in advance.
Once your files are pushed, and it’s time to put the new build live, you simply perform a “swap” action, and the new site is live in milliseconds. Your users, or even endpoint monitoring, won’t detect a difference.
This seems really advanced, it must be difficult to setup.
It’s not.
Step 1 – Create a Staged website
Within the Azure web portal, go to your Azure Website. Choose the “enabled staged publishing feature”
When prompted to create the staged version, choose Yes
Back within the Web Sites portion of your Azure Portal, expand your website node for the site you just affected, and you will see a “sub site”, with a (staged) suffix appended to the website name.
Now, go ahead and access the website settings for your new “staging” website. It’s a normal website, and you can do everything with this website that you would normally do. So now, grab your publish profile, and publish your website.
Step 2 – Push it live
At the end of the last step, I told you to grab your publish profile for your staged website. Once you published to this site, you can browse the “-staging” version of your website. If you feel your code is ready to go live, all you have to do is “swap” your deployments.
To do so, choose either your production website, or the staging version of it, and take a look at the “toolbox” at the bottom of your website:
In the toolbox, you should see the “Swap” command. This will, in essence, flip the staging and regular version of your website. When you choose “Swap”, you get a confirmation warning:
Confirm that you want to promote the site, and within a second, your site changes will be live.
“Oh Sh*t” Button
You promoted your website, and marketing calls you to tell you that some website features aren’t working as desired. You tell them they approved the website, and of course they don’t care. With staged deployment, you can just “swap” again, pushing the previous release live.. all within seconds.
Staged deployment is one of the many handy features of Windows Azure.
No comments:
Post a Comment