Automating Build – Creating A Continuous Integration Build

Our first reason for using VSTS automated builds is to help us with Continuous Integration. Continuous Integration is defined as requiring developers to integrate code into a shared repository several times a day. Each checkin in then verified by an automated build, allow teams to detect problems early.

Under the “Build” tab in your VSTS dashboard, click the green + to add a new build definition. This will popup a list of templates to pick from. The new build system in VSTS (and TFS2015 >) is task-based. This allows you to define a list of things to do in a sequence.

I am going to choose “Visual Studio” to get started with. Click Next.

Next, pick the repository your solution is in. Mine is in the TFVC repositiory within VSTS. Check Continuous Integration – this will trigger your build everytime code is checked into the repository. Finally, pick your queue. I am picking the queue I created earlier – “Home”, but there is nothing to stop you building against the hosted agent queue provided by VSTS. Click Create.

This creates some default tasks. The first (and unlisted task) is for the agent to download the source of your application from the repository. Following this:

  • Restore Nuget packages. This ensures that the build agent has any packages that your application needs in order to build successfully.

  • Next, the agent runs MSBuild to compile your solution. By default, this will build any SLN files in the downloaded repository.

  • The agent will then run tests. By default, this will look for tests in any dlls in any folders other than obj folders with the word “test” in. This is fully customisable via the settings for the task.

  • Publish symbols – publishing your symbols allows you to debug your application on a machine other than the one used to build your application.
  • Copy files to staging. This by default (and is completely customisable) copies any folders that follow the pattern of “bin\{configuration}” to the staging directory on the build agent. You can use the staging directory to organise your build output prior to outputting it to your drop server or uploading it to VSTS.

  • Publish artefact. This takes by default the staging directory on the agent and uploads it to VSTS against the build. You can customise both what you want to publish and where you want to publish it to. It can come from anywhere on the build agent, and be published to either the VSTS or TFS server against the build or to any UNC network path.

I am going to tweak my build definition to do the following:

  • Restore nugget packages. As the default – get all nugget packages for the sln file in my repository.
  • Build website and output to staging – this uses the visual studio build task, pointed at the csproj file for my MVC application, and outputting the compiled build to the staging directory. By specifying the OutDir causes MSBuild to create the _PublishedWebsites folder that we know and love.
  • Build unit tests – as I am building my web application csproj file, my unit test project is not compiled as part of that build task as it is not a dependency of the web application. So this simply builds the test csproj file
  • Run unit tests – as per default.
  • Publish artefact staging to the server – as per the default.

Why create an artefact on a CI build?

Some of you may have spotted that I am creating a drop on my CI build. Why? Because I want to practice continuous deployment – I want to deploy to my automated test environment after every build that is performed.

Other build settings

There are a number of other tabs available while defining the build:

Have a look through as there are some useful options in there – however I will just highlight Triggers:

If you check Continuous Integration when creating the build, CI will already been checked by default. I would recommend checking “Gated Checkin” as well – when ever you check in, you will be prompted to verify the checkin with a build. This places your changes in a shelveset, and runs the CI build against that. If the build completes successfully, it will then auto-merge your shelveset of changes into the main repository.

Test your build!

Now you have completed your build definition, Save your build, and queue one to test it:

The build agent will provide a realtime output to the web interface:

That’s it. You’ve got a CI build up and running.

Exploring the build summary

Once your first build it complete, you can view the build summary page:

This summary page will give a nice overview of any warnings or errors that occurred in the build, as well as your test results and code coverage.

That’s build done – next I am going to look at Release Management in VSTS to control the release process, and deploy to my environments in my deployment pipeline.

Tagged: TFS Build, Automation, Continuous Integration,
Categorised: Application Lifecycle Management,