Deploying MiniBlog from GitHub to an Azure Web App automatically using Visual Studio Team Services Build

This post covers the following DevOps practices:

  • Continuous Integration
  • Continuous Deployment

Most articles online cover how to deploy modern ASP.NET applications to Azure from code hosted in Visual Studio Team Services (VSTS) previously known as Visual Studio Online (VSO) itself. For example:

What if you want to automate the deployment of a classic ASP.NET Web Pages project, and from code hosted on GitHub? This post uses the great MiniBlog project as an example and the steps/changes I made to automate it all. At the end VSO will build and deploy it all the way from GitHub to an Azure Web App.

This assumes you already have a Visual Studio Team Services account and permissions to create and run build definitions; that you have an Azure subscription; that you have a GitHub account with access to private repos; and have a good understanding of git.

Get MiniBlog into a private repo in your GitHub account

A good practice is to have MiniBlog on your own private repo so you can make all the changes you need. To do that:

This will give you a copy of the repo on your GitHub account.

Configure the Project with a Publishing Profile

To make it easier for the build system to know I want to package the website into a zip file I configured the project with a publishing profile. Here are the steps:

  • Clone your private repo to your development environment and open the solution in Visual Studio.
  • Right click the Website project and select Publish or Publish Web App.
  • On the wizard choose Custom as the profile type and give it a name, like VSOBuildPackage. Make sure you write down this name as we will need it later. Click Next.
  • On the Connection tab choose Web Deploy Package as the type, and write website.zip as the package location. Click Next.
  • On the Settings page leave the default (Release) and click Next.
  • On the Preview page click Close and when asked to save the new profile click Yes.

These steps will have added two important files to the project that will tell the build system we want the site packaged into a zip file when publishing: website.publishproj and App_Data\PublishProfiles\VSOBuildPackage.pubxml. Finally, we need to get these changes back into your private repo:

  • Edit the .gitignore file and remove the publishproj and pubxml exclusions.
  • Make sure you include all three file changes (the change to .gitignire and the two new files) and push the changes back into your repo.

You can of course make any other changes you like to the project and customize it to your liking before pushing the changes.

Connecting Visual studio team services to GitHub

Visual Studio Team Services allows you to connect to Services and use from the new Build service. We will deploy from GitHub to Azure, so we need to connect the two to our VSO account.

  • In GitHub, create an access token and save it for later. Use the repo,useradmin:repo_hook scopes so that Visual Studio Team Services can discover private and public repositories that you have access to, create a web hook in GitHub (which is what queues the build in Visual Studio Team Services), and fetch the contents of the repository during the build.
  • Sign in to your Visual Studio Team Services account (http://{youraccount}.visualstudio.com) and go to your project (or create a new one if needed).
  • Once you are in the VSO project page, click on the small gear in the upper right corner of the page to go to the settings of the project.
  • Click the Services tab.
  • Use the New Service Endpoint + button and choose GitHub.
  • Select Personal access token and configure it with the token generated above and give it a name then click OK.

Connecting Visual Studio Team Services to Azure

Now let’s connect to your Azure subscription where the website will be deployed.

  • Like with the GitHub connection, sign in to your Visual Studio Team Services account and go to the Services tab of the settings page of your project.
  • Click the New Service Endpoint + button choose Azure.
  • Fill out the details of your subscription and choose one of the ways to connect to your Azure subscription. I went with the certificate option.

Now you should have both your GitHub and your Azure subscription connected to VSO as below.

Create a Build Definition

Now we can created the build definition that will get the solution from GitHub, build it, and deploy to an Azure Web App.

  • From your Visual Studio Team Services project click on the Build tab.
  • Click the plus sign to create a new build definition.
  • Choose the Visual Studio template and click OK.
  • On the new build definition, click on the Repository tab and change from the default git (this is the git repo of your Visual Studio Team Services project) to GitHub. Then on Repository choose your private MiniBlog repo as per below and leave the default for the rest.
  • Click the Variables tab and change BuildConfiguration to release if not already.
  • Change back to the Build tab.
  • For the purpose of this post we will not be running any tests and will publish to Azure, so delete the Visual Studio TestIndex Sources & Publish Symbols and Publish Build Artifacts steps by hovering over each step and clicking the X button that shows up as per below.
  • Click the Add Build Steps button.
  • From the Deploy list click Add next to Azure Web App Deployment and click Close. We now have our build definition with the two steps we need to configure.
  • On the Visual Studio Build step configuration , click the … button next to Solution. This lets you browse through your GitHub code repo to choose which project you want to build. Choose the website.publishproj file in the Website folder.
  • On the MSBuild Arguments setting enter this to ensure it will package the project and follow our choices from the publish. file: 

/t:Package /p:PublishProfile="App_Data\PublishProfiles\VSOBuildPackage.pubxml" /p:DesktopBuildPackageLocation="$(build.stagingDirectory)" /p:SkipInvalidConfigurations=true

  • Note that above I have VSOBuildPackage.pubxml as the publish file. Change that to the name of the publish package you created earlier if you used a different name.
  • Untick Restore Nuget Packages and leave the rest of the settings as default. Your Visual Studio Build step should look like the below.
  • Now change to the Azure Web App Deployment step.
  • It should have pre-selected your Azure subscription (or choose the one you want to use if you have more than one connected).
  • On the Web App Name field enter a name for your new Web App (if you had already previously created and empty Web App on Azure for this then enter that same name here).
  • On Web App Location choose where you want your website deployed (if you had already previously created and empty Web App on Azure then enter the same location here).
  • On the Web Deploy Package enter $(build.stagingDirectory)\**\*.zip for it to use the zip file that the Visual Studio Build step will create.
  • Finally, click the Save button on the build definition and give it a name to save your Build Definition.

Run a build & check out your new blog site!

Now that we have finished configuring the build definition it is ready to be run. Click the Queue Build button and click OK on the pop up to manually trigger a build.

You should then see the build steps executing:

And once done the status of the build should be Build Succeeded. This means it got the code from your private GitHub repo, ran it through the Visual Studio Build step that generated a zip file with the website content, and then deployed it to Azure to a new or existing Azure Web App.

You can now browse to your new website URL and see it running:

Enable Continuous Integration

Finally, let’s enable continuous integration.

  • Go back and edit your Build definition in Visual Studio Team Services.
  • Select Edit.
  • Change to the Triggers tab.
  • Click the enable Continuous Integration check box and click Save.

And that is it, this will queue a new build every time you check in code into your private GitHub repo.

For extra points, you can add a 'build badge' image to your MiniBlog site to show the latest build status, I describe this on this other blog post.