Visual Studio Online (VSO) has provided many tools to expand upon past simply serving as a source control repository. From managing work items to providing tools for automated tests and now officially supporting Git, it has grown greatly since its inception. One of the newer and more useful features provided is the ability to write and execute build definitions. These build definitions can be used to deploy code to test and production environments, enable automated unit testing, and much more.
This post assumes you have a basic understanding of Microsoft's Azure cloud hosting platform. The test application created for this post is hosted in Azure and that is the environment you will be deploying to. I won't go over the details here, but I will assume a Web App is created for the application and exists in Azure. Additionally, I will be using Git as the source control system for this project. Git is quickly becoming the standard source control system for software development, and has gone from being supported by VSO to becoming a first-class citizen. Many of the tools in VSO did not support Git until recently.
Before moving any further, it makes sense to talk about the advantages of using build definitions for any project hosted in VSO. For many projects, build definitions are used as a means to implement continuous integration (CI). CI is a practice that works best when developers check-in their code to a central repository as frequently as possible, where an automated build verifies that a given check-in produces a repeatable build, and can then run other steps such as unit tests to verify code quality. This automation can be managed using VSO build definitions, with steps available to deploy code to Azure, perform unit tests, package code, and much more. We are implementing a very basic example of CI in this example (build each check in and deploy to a test environment), but it is worth noting that the realm of continuous integration is much more broad than what is covered here.
You can create a build definition directly from VSO or from within Visual Studio. To create a build definition from within Visual Studio, navigate to the 'Builds' tab in the Team Explorer:
Once there, you can click 'New Build Definition' to be taken directly to VSO. This would be where you would start if you had decided to create the build definition directly from VSO instead of starting in Visual Studio. On the dialog box that pops up in the browser, we will select 'Visual Studio' as our build template, but you can see that there are other templates for use, such as Xamarin for Android or iOS and the Universal Windows Platform. The default settings for your build definition should be correct for the most part, but you will need to check the 'Continuous integration' checkbox. Here is a look at what they look like for this example:
Because this is a simple example and we don't need the additional flexibility the Default queue provides, we can leave the default 'Hosted' option selected in the 'Default agent queue' field. For more information on the restrictions on the Hosted pool, see https://msdn.microsoft.com/en-us/library/vs/alm/build/services/hosted-agent-pool.
You can see the checkbox for CI at the bottom of the dialog. This is enabled so VSO will execute the defined build definition for each check-in. The build definition will define whether or not this build code is published to an environment or not. Since we want to continually build and deploy to our web environment, we will check this box.
After clicking 'Create' you will be taken to the 'Definitions' page of the build definition you just created. You will see that there are already some build steps included by default. For the purposes of this example, we are creating a build definition that is very simple and only has four steps - restoring NuGet packages, building, deployment, and publishing symbols. It is for this reason that we can remove the 'Visual Studio Test', 'Copy Files', and 'Publish Build Artifacts' steps. These are very useful definitions, but beyond the scope of this post. We will also add a step that helps simplify publishing directly to an Azure Web App. To do this, click 'Add build step…' and find the 'Azure Web App Deployment' step:
Once that is complete, you should have a build definition that looks something like this:
There are a few important steps to take to configure your Azure build step. You can choose an Azure Subscription that is linked to your account, or setup a connection using the 'Manage' link to the right of the box with credentials from a publish profile. You also need to make sure you enter the name of the Web App you want to deploy to.
You also need to make sure that the step for the 'Visual Studio Build' is configured correctly. By default, the MSBuildArguments field is left blank; you will need the .zip artifacts when deploying to Azure, so you can add the following arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"
Once this is configured, you can add the folllowing value to the 'Web Deploy Package' field of the 'Azure Web App Deployment' step:
This tells the deployment to look in the staging directory for the artifacts produced by the Visual Studio build step. If not configured properly, the Azure deployment step will not be able to find a deployment package and the build will fail.
If you navigate to the 'Triggers' tab, you should see that the CI box is checked, and it will run each time code is checked in to the appropriate branch (in this case, master):
To test this, make a visible change in your project and commit the change to the master branch. After a while, you should see a queued build:
Once the build has succeeded, you can navigate to your web app and verify that the change has been pushed to the Web App.
Hopefully this blog post has helped you understand how you can leverage Microsoft Azure build definitions to implement a CI process for your applications that are hosted in Visual Studio Online.