Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
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.
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.
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.
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).
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.
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.
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.
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.
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.
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)
(They sponsored the Global Windows Azure Bootcamp in Irving, TX and did an awesome job presenting)
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.
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.