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
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
Packaging and deploying your application
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
What does CS stand
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.
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
Ã‚Â§ 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
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
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.
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
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.
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
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.