This is an ongoing series on Window’s Azure. The series starts here, and all code is located on GitHub: https://github.com/mmooney/MMDB.AzureSample. GitHub commit checkpoints are referenced throughout the posts.
In the previous posts we covered setting up a basic Azure-enabled web site and setting up your Azure account. In this post, we’ll show you how to deploy that website to Azure. First we will deploy through the Azure web UI, and then directly from Visual Studio.
Azure Deployment Package
In order to deploy your website to Azure, you’ll need two things, a deployment package and a configuration file:
- Deployment Package (.cspkg): This is a ZIP file that contains all of your compiled code, plus a bunch of metadata about your application
- Configuration File (.cscfg): This is an environment-specific configuration file. We’ll get into this more later, but this lets you pull all of the environment-specific configuration away from your code which is definitely a good idea.
So go back into your solution that we build in an earlier post (or grab it from GitHub here). To deploy this project, you will need a MMDB.AzureSample.Azure.cspkg file. But if you search your hard drive, you won’t find one yet. To create this package, you’ll need to right click on your Azure project and select “Package”
This will create the package, and will even launch a Windows Explorer window with the location (which is helpful, because it can be a little tricky to find:
And there are our two files we need to deploy.
Deploying Through Azure Website
So now that we have our deployment package and config file, let’s go back into the Azure website (https://manage.windowsazure.com/) and log in.
We want to create a new Cloud Services project, so let’s click Create An Item and drill down to Compute->Cloud Service –>Quick Create:
We’ll enter our URL, which will end with .cloudapp.net, but does not have to the the final name of your website.
We’ll also select a Region/Affinity Group, which is where your servers will be hosted. Select somewhere closest to where your biggest user base will be. The different areas in the US don’t make a huge difference, but US vs. Europe vs. Asia can have a big impact.
So then we click Create Cloud Service, and we have ourselves a cloud service:
Now we’ll go ahead and set it up. Click the little arrow next to the service name, then Upload A New Production Deployment, and start filling in the details:
Enter a name for your deployment. This is specific to this deployment, and the idea is that it could/should change on subsequent deployments. I usually try to put the release version number in there.
Also browse for your package and config file, and select Deploy even if one or more roles contain single instance (which is in fact the case with our simple little test app), and select Start Deployment:
Click the checkmark button, and then go get yourself a cup of coffee. This is going to take a few minutes.
Oh you’re back already? Go sneak out for a smoke, we have a few more minutes to go:
This is one of the downsides to Azure, these deployments can take a while, especially for new deployments. Down the line we’ll show you how to automate this so you can click a button and walk away for a while, but for now just keep watching.
Ok, so after about 5 minutes, it looks like everything is running. We can click the Instances tab to see more detail:
Back on the Dashboard screen, if you scroll down, you’ll see a whole bunch of useful stuff:
Including the Site URL. Try clicking that and let’s see what we get:
Hey, there’s our website! Nice.
Deploying Through Visual Studio
Now that you’re familiar with the Azure website, we can also deploy right from Visual Studio.
Let’s go back into Visual Studio, right click our project, and select Publish:
Now we’ll set up our subscription details. Under “Choose your subscription”, select “<Manage…>”, and then click the New button, and that will take you to the New Subscription screen:
We’ll need to create a management certificate, so under the dropdown select “<Create…>”, enter a name for the certificate, and click OK.
How that we have that, upload that certificate to the Azure portal web site. Click the link to copy the path and then the link to go to the Azure portal:
Select the certification (using the path in your clipboard) and click OK.
OK, now that we’ve uploaded our certificate, let’s go back to the New Subscription screen. Next it’s asking for our subscription ID, which is back in the Azure portal. Paste that in, give a name for your subscription, and click OK:
And now we’re all the way back to the publish screen. Now we’ll use that subscription click next, and …
…and now it’s asking to create an Azure storage account? Why?
The reason is that when you deploy right from the Azure portal website, it does everything all at once on the server. However, when you deploy from the Visual Studio (or from Powershell, which we’ll get into later), it first uploads the package to the storage account and then tells Azure to deploy the package from there.
Let’s enter the name of our new storage account and location (yes, it’s a good idea to use the same location as the Region/Affinity Group you entered above) and click OK
Now we have some nice default settings to deploy with, and so let’s click Publish:
It may ask you to replace the existing deployment, and that is OK:
Now this will run for a while, and will take about as long as the deployment from the website.
What to be careful of
- When deploying through the website, make sure you build and package each time before you deploy. If you are deploying from Visual Studio, it will automatically package everything for you. However, if you build your project but forget to package it, and then upload the package to the Azure website, you’ll be uploading and older version package. This is the type of thing that can cause a lot of time wasted trying to figure out why your new changes are not appearing.
- Also, as a general rule, deploying right from your development environment is bad bad bad. All of the awful reasons are long enough for another blog post, but in short you really want to have an independent build server which is responsible for pulling the latest code from source control, building it, running any tests it can, and publishing it out to Azure.
Next, we’ll cover another key part of Azure deployments, which is deploying via command line. While deploying from Visual Studio and the Azure portal is easy when you’re getting started, eventually you’re going to want to automate this from a build server.