Shaun Xu

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.

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.

 

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.

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.

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

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.

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.

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

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.

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

 

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.

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

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.

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

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.

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

And the website are updated as well.

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.

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

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

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

Then swap the staging and production slot.

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.

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

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

 

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

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

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

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.

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.

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

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.

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

 

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

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/eO6

Posted On Thursday, January 23, 2014 11:02 AM
Filed Under [ Microsoft Azure ]