Kirk Evans Blog

.NET From a Markup Perspective

Deploying an Azure Web Site Using Git and Continuous Integration

Deploying an Azure Web Site Using Git and Continuous Integration

Rate This
  • Comments 3

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. 

Background

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.

image

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.

image

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.

image

The wizard asks you for a name and a location.

image

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.

image

Click Save to save your settings.  Click Yes for the friendly confirmation message.

image

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

image

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.

image

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.

image

Go to the dashboard tab for the staging web site, and under the Quick Glance section choose “Set up deployment from source control”.

image

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.

image

You now have to authorize the connection so that Visual Studio Online will have the right permissions to push to the Azure web site.

image

You will see a connection request that you must Accept. 

image

Finally, we see the connection was successful and we choose a repository to deploy from.

image

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.

image

Click that.  You are then prompted if you really want to allow the web site to open Visual Studio (you do, you really do).

image

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.

image

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.

image

I’ll create a new Web API project, which includes ASP.NET MVC and does not authenticate the user.

image

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. 

image

Enter a check-in comment and click Commit.

image

We now want to push our changes to the remote repository, so click the Sync link.

image

Next, click the Sync button.

image

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.

image

Double-click the running build (under My Builds (1)) and you will see the status of the current build.

image

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.

image

IT.  IS.  ALIVE!!!!

image

Remember that we are on the staging web site. 

image

We haven’t done anything to production yet.  Let’s go check the production URL.

image

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

image

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)

image

Click Yes.

image

Refresh the page for the production web site.  Make sure you aren’t holding liquids near your keyboard, because this is way too cool.

image

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.

image

We see the file is checked out when we edit, so we need to commit.

image

Enter a check-in comment and click Commit.

image

Sync your changes.

image

Go look at the Build tab again!

image

Once it is complete, we go look at the staging site.

image

Aw heck, just because it’s fun to do, let’s go swap staging and production.

image

And now production has the correct version of the web site.

image

For More Information

Git for Team Foundation Developers

Git for Team Foundation Developers – Branches

Git for Team Foundation Developers - Merging

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)

Opsgility, Windows Azure Training Experts (They sponsored the Global Windows Azure Bootcamp in Irving, TX and did an awesome job presenting)

  • Hey Kirk,

    Great post (and your git rampup ones are great too)!  I followed your steps and have everything working, however when I change something as simple as a View or html file and do a "commit + push", the entire solution rebuilds on the build server in VS Online and a re-deploy of the compiled code is done.  This results in an app pool reset which is less than ideal.

    Do you know of a way to get VS Online build to only deploy the changed files, or to not do a compile (and deploy) of the comopiled dll if it hasnt changed and to only deploy the static files?

    A similar issue is that my build/deploy takes ~3 minutes to complete even after changing just a html file - this obviously eats into my "60 free minutes" very quickly when I only wanted to "easily" deploy a html file via Git and CI.

    Regards,

    Matt

  • Thanks Matt!  Glad you are finding the content useful.

    You're right, making a change to the view results in the DLL being pushed.  I confirmed this by skipping all the VSOnline stuff and just publishing directly to the Azure web site.  The .cshtml file and the web DLL are both deployed to the server, resulting in an app pool reset to load the new DLL.  If you change only an HTML file, then only the HTML file is deployed to the server, thus avoiding an app pool reset.  

    One way to limit the consumption of your free build time is to publish changes directly from Visual Studio to the Azure web site to test.  You can continue to commit changes to your local repository, which doesn't affect the automated build.  When you are finally ready to push changes from your local repo to VSOnline, then you push the changes to the remote repo, triggering an automatic build.  This would greatly limit the amount of consumption that you have against build time.

    If you are concerned about having those changes local and not on the server, then create another branch (such as "dev") and publish that branch to the server without configuring automated builds for that branch.  When you are ready for automated builds to occur, merge your changes from the dev branch back to the branch where builds are configured and publish to VSOnline, triggering a build.

    This is how my team is running our project.  We create feature branches and bug fix branches, neither of which have automated builds configured.  We commit changes to that branch and publish to the server.  When that feature is complete, we merge from the feature branch to the main branch, triggering an automated build.

  • Thanks for your insights on saving on build time - for me its more about the app pool reset though.  At least until I lose my early adopter status :-).

    I got the same results as you via Publishing from VS2013, however if I publish via VSOnline after simply changing the html file it still pushes the dll after doing a recompile of the code.  Would love to know if there is a way to change the Build Definition (I assume) to get it to check for any new files first.

    Regards,

    Matt

Page 1 of 1 (3 items)
Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives