.NET Tutorials, Forums, Interview Questions And Answers
Welcome :Guest
Sign In
Win Surprise Gifts!!!

Top 5 Contributors of the Month
Sandeep Singh

Home >> Articles >> Azure >> Post New Resource Bookmark and Share   

 Subscribe to Articles

Creating a Cloud Service package for deployment

Posted By:Manning       Posted Date: February 25, 2011    Points: 100    Category: Azure    URL: http://www.dotnetspark.com  

Creating a Cloud Service package for deployment. The authors explain how to package your website and move it to the cloud.

This article is taken from the book This article is taken from the book Azure in Action. The authors explain how to package your website and move it to the cloud.


Get 40% off any version of Azure in Action with the checkout code dnspark40. Offer is only valid through www.manning.com.

After you build a website and sign up for Azure, it's time to deploy your cloud application. In this article, we'll show you how to deploy a basic website that sells Hawaiian shirts. If you've ever developed a website with ASP.NET, you're already ahead of the game-you'll soon see that the steps to deploy an application with Azure are far fewer than those required with a traditional server.

Packaging and deploying your application

Suppose you've set up an Azure account, you've created a hosted services project, and you have some parts for an application sitting on your local disk. Now you're going to take your application and its configuration and create a CS package for deployment.

What does CS stand for?

You'll see the acronym CS throughout the SDK and the tools for Azure. VB.NETers don't need to get upset; CS doesn't stand for C#, but for Cloud Service.

One way to create the package is to use the CSpack utility in the SDK. Although this is great for scripting, it can be tedious for those who live inside Visual Studio all day. A quicker method is to right-click the Azure project in your solution (for

example, our sample project would display as AiA CH02 - Hawaiian Shirt Shop) and choose Publish.

The publish command calls CSpack for you, which creates the package, opens a file explorer window that points to where the package files are placed, and then opens a browser window to your Azure project portal page. The steps from here are simple:

§  Sign in to your portal, and then select the project you want to deploy in the Windows Azure section on the left. By default, only the production environment is displayed.
§  Click the small arrow on the right side of the screen to show the staging environment.

§  Click the Deploy button under the gelatinous staging cube, and use the screen to upload the package and the configuration file from the file explorer window that was opened for you.

TIP: After you select the package and configuration files, we suggest that you use the text box on the bottom of the form to give the deployment a label for history purposes. We usually use either a build number or version number, but the label can be anything you want. In this example, we're going to enter version 1, build 14, ch2 sample preview, sp1 spring refresh.

After you click Deploy, the files are uploaded and you're redirected to the service page on the Azure portal. You can choose to deploy directly to the production environment, but we recommend that you always deploy to the staging environment first. When the files are uploaded, the state of the service is set to Stopped.

Deployment is as easy as uploading a few files and clicking Run-at least for you. For Azure, the Fabric Controller kicks in, identifies some unused CPU cores, deploys a virtual server image, copies over your bits, wires up a VLAN for your instances only, reconfigures the load balancers, and then updates the service directories.

While all of this is happening, which can take from seconds to minutes depending on what you're deploying, you'll see the status of your environment flip to Initializing. When Azure is finished, the status changes to Started. When things are deployed, the cube turns a nice shade of blue, and the status flips to Staging, as shown in figure 1.

Note that servers are reserved for you when you do the initial upload of your code with the Deploy button and before you click Run. At this point, the cube turns blue and you'll be charged, even before you click Run. A little saying to remind you when you'll be charged is "If the cube is grey, you're O.K. If the cube is blue, a bill is due."

Figure 1 The sample application has been deployed to the staging environment and is fully initialized. It's assigned an easy-to-remember GUID-based host name so that you can test your deployment.

While your application is in the staging environment, it has a temporary URL with a GUID as the host name of the service. The friendly name you picked when you created the Azure project won't be used until you migrate your application to production. Before you do that, test your application while it's in staging by using the temporary URL, which is located toward the bottom of the window.

When your application is running, the Run button changes to a Suspend button. If you click this button, you'll take your application offline. Azure is stopping the IIS application in the background when you do this and, even though it's suspended, you're still using a VM; the Azure hours for your billing continue to accrue.

Now that you've tested your application in the staging environment, you can move it to production.

Moving to production

Remember, when you move your application to production, you aren't moving the application or the settings. When you flip the button, Azure reconfigures the fabric to route all new traffic from the outside world to this particular instance. The old production environment becomes a new staging environment. Because nothing actually moves, you can easily roll back to the old version if things go wrong.
To move your application to production, click the circular arrows in the center of the screen. When you click them, you're prompted to make sure that you want to do that, and then the magic happens. Because Azure is making only a small configuration change, the cutover takes only a moment.


Deployment is almost a trivial matter. It doesn't take a lot of effort to create a service, upload the package, and promote it to production. The simple staging and production environments make it easy to roll back to the old code in case the new deployment goes horribly wrong.

Now that business is rolling in, you'll want to monitor how much your application is costing you. Microsoft provides detailed information about your usage of the Azure platform on a regular basis. You can view these reports at any time on the Azure portal.

Azure in Action

Chris Hay and Brian H. Prince
October 2010 | 488 pages
ISBN: 9781935182481

 Subscribe to Articles


Further Readings:


No response found. Be the first to respond this post

Post Comment

You must Sign In To post reply
Find More Articles on C#, ASP.Net, Vb.Net, SQL Server and more Here

Hall of Fame    Twitter   Terms of Service    Privacy Policy    Contact Us    Archives   Tell A Friend