Shaun Xu

The Sheep-Pen of the Shaun


News

logo

Shaun, the author of this blog is a semi-geek, clumsy developer, passionate speaker and incapable architect with about 10 years experience in .NET. He hopes to prove that software development is art rather than manufacturing. He's into cloud computing platform and technologies (Windows Azure, Aliyun) as well as WCF and ASP.NET MVC. Recently he's falling in love with JavaScript and Node.js.

Currently Shaun is working at IGT Technology Development (Beijing) Co., Ltd. as the architect responsible for product framework design and development.

MVP

My Stats

  • Posts - 94
  • Comments - 335
  • Trackbacks - 0

Tag Cloud


Recent Comments


Recent Posts


Archives


Post Categories



On 16th Jan, the "Gu" announced several features in Windows Azure in his blog, one of them is "Website Staging Support ". With this feature we can deploy our application to the staging slot of our Windows Azure Website (a.k.a. WAWS) for test purpose. And if everything is fine we can simply "SWAP" to the production slot without any down time and within few seconds. If you have been working with Windows Azure Cloud Service, this feature is very similar.

But since this feature is still in preview phase, there's some restricts. If you specified the deployment source of your WAWS, when you opened the staging feature, you might be encounter some problem and in this post I'd like to explain and the workaround.

 

Common Deployment Pattern before Staging Feature

Before we have staging feature available, if we'd like to continue deploy the Beta version our application to WAWS, we might be using the branch feature of our source code provider. For example, when we are using GitHub, we can create two branches in my repository: master and beta. Then I created two Website one of it connected with master another with beta.

image

In this way I can deploy the new version in beta branch and keep my beta WAWS deployed automatically for test purpose. If the test was passed I will merge my changes from beta to master branch. This will trigger the master WAWS deployed so that the new version will be available in my production site.

image

 

Staging Slot and Swap

By enable WAWS Staging feature, we don't need to create two websites and two branches as below. First let's enable the staging feature in my WAWS. Just in the general tab of my WAWS, let's click "Enable staged publishing" button.

image

You have to upgrade your WAWS to standard mode to enable this feature. Free and shared mode doesn't support staging right now.

Then in the WAWS list we will find another item appeared under my original WAWS with "staging" in its name. Also it has a URL with "-staging" as well.

image

Then let's click into the staging item, set the deployment from my GitHub repository.

image

Once I push any code changes the staging site will pull the code and deploy them into the staging website. Below is a MVC website deployed to my staging site.

image

And when I visited the staging website I will find the application had been deployed. In order to make future discussion clear I displayed the application version in the site content.

image

Now if we opened the website production URL there will be nothing since our code was not deployed.

image

Now I can clicked the "SWAP" button in azure portal. This will switch my staging and production site, very similar as the feature in Cloud Service.

image

After that we will find the website appeared in my production slot while my staging slot turned to empty.

image

 

Problem When Next Commit

Now let's change our code and commit again. Since I had enabled the GitHub deployment in my staging slot, in theory it should be deployed to my staging slot automatically. But after waiting for several minutes there's no deployment appeared.

image

And in the production slot since we didn't enabled the deployment source there's no "deployment" tab we can click.

image

So this is the problem if we are using GitHub deployment against the staging feature.

I didn't tested other deployment sources such as TFS, local Git but I think they should have the same problem since all of them are using the same deployment mechanism.

 

(My Guessing) Reason and How Staging Implemented

From the phenomenon of swapping slots I guess this is because deployment repository on WAWS are separated between production and staging slots and the swap operation just changes the DNS setting.

So when we enabled the staging feature in my WAWS and integrated with my GitHub, my staging slot contains the deployment repository and staging slot was register as "integrated". Then when I committed the code staging slot was get updated successfully.

image

When I clicked "Swap" the DNS setting was changed.

image

Now if I committed code changes, my staging slot was registered as integrated but since currently it was linked with my production environment, the source code cannot be pulled since no repository available. My production slot linked with the environment which contains repository but it was not registered as integrated. So I think this is the reason why my next code commit was not getting deployed once swapped.

image

If I swapped back and committed another version then my staging slot deployed automatically.

image

And the website are updated as well.

image

But this is NOT what I wanted. I wanted the staging slot getting deployed automatically while production slot should be updated only by swapping.

 

Workaround by David Ebbo

This problem was reported in Windows Azure MVP mail-list. David Ebbo from Microsoft confirmed that this is an issue of WAWS staging feature and will be solved in the future releases. For now he provided a workaround to make staging slot continue deployed with GitHub only.

Now let's create a new WAWS and enable the staging feature. After that we need to enable GitHub deployment on both of the production and staging slot.

I also recommended to create a new clean GitHub repository before you set up the deployment. Because once you set up the deployment WAWS will fetch your code and run the deployment. If you have existing code in your repository both staging and production will be deployed and this will cause some problem in the future.

Next step, we need to go to GitHub and cut down the hook to the WAWS production slot.

image

Selected "Service Hooks" and "Webhooks URLs" there should be two items. We should find "__staging" string in one of them which is the hook to our WAWS staging slot, and the other one is the hook to production slot. What we should do is to remove the hook WITHOUT "__staging" and click "Update settings."

image

After this step our GitHub repository hooks should be like this.

image

Now let's create a new MVC website and push the codes to GitHub then we will find only the staging slot got deployed.

image

Then swap the staging and production slot.

image

Now let's commit some changes and push to GitHub. We will find the staging slot got deployed with version 2 while the production slot still in version 1.

image

Now swap again to move the version 2 to production slot.

image

And then update our code to version 3 and push, the staging getting deployed again successfully.

image

 

(My Guessing) How Workaround Works

The workaround mentioned above utilizes the GitHub hook feature. Firstly we enabled the deployment on both staging and production slots so that in Windows Azure side both of them could connect to GitHub to deploy our application.

image

When we removed the production hook in GitHub, this slot will not be able to deployed automatically due to failed to connect to GitHub.

image

Then we when pushed a new version, only staging slot got the hook notification and began the deployment.

image

When we swapped the slots, the DNS was changed but the hook still connected with the staging slot with the URL (I guess). So the staging still be able to get the GitHub hook notification now.

image

Now if we pushed a new version to GitHub it will notify the hook to the staging URL and now the staging URL connected to another slot (previously production slot). So the staging can be deployed again.

image

And when we swapped the DNS switched again and the new version will be deployed to staging if we pushed version 3.

image

If we went back to azure portal, the deployments will be shown in our WAWS. If we visited the staging slot the deployments should be initial commit, v1 and v3.

image

While the production slot shows initial commit and v2. Just the same as what I guessed above.

image

 

Summary

In order to make the cloud environment testing easier Microsoft introduced the staging feature in Windows Azure Website. With this new feature we can deploy our application to staging slot and test, then swap to the production slot within few seconds.

If we want only staging slot continue deployed with our source control source we need some workaround at this stage. But I think in the near future this problem will be fixed, maybe when it's GA.

I only covered the case when using GitHub deployment. But I think we can leverage the same approach against other source control services like Visual Studio Online, CodePlex, etc..

 

Hope this helps,

Shaun

All documents and related graphics, codes are provided "AS IS" without warranty of any kind.
Copyright © Shaun Ziyan Xu. This work is licensed under the Creative Commons License.

Comments

Gravatar # re: Windows Azure Website Staging Feature and GitHub Integration
Posted by Max Battcher on 1/24/2014 12:07 AM
This might help with your understanding of the process: in your guess towards the bottom the arrow of your hooks are backwards. The hook tells GitHub to send an HTTP POST on a new commit to the specified address, essentially telling it new commits are available for processing (in this case the process is the deployment process on Azure). Thus by removing the Production hook you are removing that notification of new commits being sent to Production. Hope that helps your mental picture of what is happening.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: