This post will show how to deploy an Azure Web Site using Git and Continuous Integration. By the time I typed that long title, I’ve told you pretty much the whole story.
I attended the Global Windows Azure Bootcamp today and had a blast going through labs and watching demos. Sure, most of it was stuff I already knew, but there’s always some new trick you pick up that makes it completely worth your while. This post covers one of those tricks that I learned from Rick Rainey (co-founder of http://opsgility.com and @rickraineytx on Twitter), and it fits very nicely with the stuff I’ve been blogging about lately: deploying an Azure web site using Git.
I wrote a previous post showed how to deploy an Azure web site for a SharePoint-hosted app using Visual Studio 2013. In that post, I showed how to use the integrated tools to deploy a web site to Azure straight from your desktop. What would be nice is if we could target the hosted build controller in Visual Studio Online using continuous integration to automatically deploy the web site to Azure anytime there is a new commit to the source code repository.
This post is long just because I took a bunch of screen shots. Doing all of this takes maybe 5 minutes, especially once you understand what’s going on.
Create a Team Project in Visual Studio Online.
Go to Visual Studio Online and create a new team project, choosing Git for version control.
When that’s complete, Close the window. You could navigate the project and check out how awesome the Visual Studio Online dashboard is, even define some sprints, create some project backlog items, and elaborate tasks.
We’re not covering those features today, but we’ll come back to Visual Studio Online in just a minute.
Create a Standard Web Site with Staged Publishing
In Visual Studio 2013, go to the Server Explorer pane, log into your Azure subscription, and then choose Add New Site.
The wizard asks you for a name and a location.
Once created, we go to the Azure Management Portal and click on our web site, then choose Scale. On the Scale tab, change the web site mode from Free to Standard.
Click Save to save your settings. Click Yes for the friendly confirmation message.
After a few minutes, the operation is complete. We now go to the dashboard for the web site. Under the Quick Glance section, click the link to “Enable staged publishing”.
This is going to enable our web site to have a staging and production site. Once completed, there will be a new staging web site with a different URL nested below the production one.
Set Up Deployment from Source Control
This part makes me giddy with joy, it really does. Open the staging web site (the one that has “(staging)” appended to it, you should be on a page that looks like the picture below. Notice the “(staging)” appended to the end of the web site name, that’s going to be important in a minute.
Go to the dashboard tab for the staging web site, and under the Quick Glance section choose “Set up deployment from source control”.
Azure asks where your source code lives. We tell it to look in Visual Studio Online. Notice, though, that we can deploy from a local Git repository, from GitHub, heck even Dropbox! Other options include Bitbucket, Codeplex, or a publicly-accessible repository using Git or Mercurial. Of course, we will choose Visual Studio Online because awesome. Because awesome.
You now have to authorize the connection so that Visual Studio Online will have the right permissions to push to the Azure web site.
You will see a connection request that you must Accept.
Finally, we see the connection was successful and we choose a repository to deploy from.
Once that completes, you’ll see a confirmation screen that the team project is linked, and you will see a Visual Studio logo at the bottom of the screen.
Click that. You are then prompted if you really want to allow the web site to open Visual Studio (you do, you really do).
Create an ASP.NET Web Site
Once Visual Studio opens, the Team Explorer pane shows your Visual Studio Online team project information (oh, that’s so cool… we opened the project from Azure, but by virtue of linking Azure to VSO we now get our team project to show). Click the “New” button under Solutions.
In the New Project dialog, I will create a new ASP.NET Web Application named DemoWebApplication. Leave the checkbox to add to source control checked, we need that to create a Git repository.
I’ll create a new Web API project, which includes ASP.NET MVC and does not authenticate the user.
Once that’s complete, I have my web site project and my local repository.
Note: when trying this, I ran into a weird error where Visual Studio tried to put my project into a different repository and I got weird behavior trying to add the web site project. If this happens to you, just close and re-open Visual Studio, go to the Team Explorer, and choose to Clone the repository to a new working directory. I show you how to do this in my post Git for Team Foundation Developers.
I then right-click the solution and commit.
Enter a check-in comment and click Commit.
We now want to push our changes to the remote repository, so click the Sync link.
Next, click the Sync button.
We now have committed our changes to Visual Studio Online.
Stand Back in Amazement
Now for the truly inspiring moment. If you go to the Builds section in Visual Studio’s Team Explorer pane, you’ll see there is a build definition already created for you. Even better… the build is probably already running.
Double-click the running build (under My Builds (1)) and you will see the status of the current build.
ZOMG. I just peed myself a little. That is so awesome.
Once it is done, you see that the build succeeded. You could view the log, open the drop folder, yadda yadda yadda… let’s go look at the web site! Click the link under Deployment Summary to go to the web site.
IT. IS. ALIVE!!!!
Remember that we are on the staging web site.
We haven’t done anything to production yet. Let’s go check the production URL.
We haven’t pushed code to it yet.
Swap Staging and Production
When we enabled staged publishing for our web site, it enabled us to have a staging web site and a production web site. Azure will simply swap the pointers between them when you tell it to. This is incredibly useful for things like automated Build Verification Testing to test the staging site as part of your build process. You can make sure everything works in staging before swapping to production.
Go to the Azure Management Portal and go to the Web Sites node. You will see a button that says “Swap”.
Click it, this will swap your staging and production sites.
Another nice friendly confirmation message click Yes (I know you’re as antsy as me to see this… just so cool to me)
Refresh the page for the production web site. Make sure you aren’t holding liquids near your keyboard, because this is way too cool.
Do It All Over, Just Because You Can
Let’s make a change to the web site. I go into the Views / Home / index.cshtml file and make an edit.
We see the file is checked out when we edit, so we need to commit.
Enter a check-in comment and click Commit.
Sync your changes.
Go look at the Build tab again!
Once it is complete, we go look at the staging site.
Aw heck, just because it’s fun to do, let’s go swap staging and production.
And now production has the correct version of the web site.
For More Information
Creating a SharePoint 2013 App With Azure Web Sites (my blog post showing how to use Azure web sites, if you were building an app for SharePoint you could totally do everything in this post as a provider-hosted app)
Building SharePoint Apps with Windows Azure Platform as a Service (my one-hour talk at SharePoint Conference where I covered a bunch of stuff with Azure web sites and platform as a service stuff)