Builds

The job of a build is to extract the source code, compile it, run unit tests, and produce an artifact.

Simple Pipeline.png

The artifact is then released into a given environment.

A build definition is comprised of a set of tasks. There are many tasks available for Visual Studio Team Services. Microsoft claims to support any platform and any language. Let’s take a look at the build definition tasks for the sprint.

BuildTasks1.png
  • Get Sources – This task retrieves the source code for the Sports Store solution for the sprint.
  • NuGet Restore – Builds are run on an agent. This task restores any NuGet packages required by the solution.
  • Version Assemblies – This task updates the AssemblyInfo.cs file with the version number generated by the build. We will further discuss this a bit later.
  • Build Solution – This task compiles all of the code in the Sports Store solution. Any compiler errors  will break the build and halt the execution of future tasks.
  • Test Assemblies – This task executes the unit tests specified in a set of DLLs. We also specifically execute only unit tests with a TestCategory of CI_Build. These unit tests are mocked and run quickly.
BuildTasks2.png
  • Publish symbols path – This task publishes the debug symbols created by compiling.
  • Copy DB / Unit Tests to – This compiler task places the files needed for deployment into a staging directory for the website. The database and unit test files are also copied to that staging directory as well.
  • Publish Artifact – This task copies the files in the staging directory to a single location called Drop, which is comprised of the artifact that will be deployed.
BuildTrigger.png

The above screenshot shows how we configure triggers. In this case, we have configured a trigger to run the build whenever the current branch, Sprint_13, changes. Sprint 13 is our current branch.
We always want to know what version of Sports Store has been deployed.

VersionNumberConfig.png

Each release uses a version number. We use Semantic Version numbers, which gives us version numbers like 1.1.0. Each time a build is run, the build number is incremented and added to the end of the version. Using the example above, the fourth build would result in a version number of 1.1.0.4. This version number is displayed on the user interface of Sports Store.

We can use this information to track back to the build and a set of code in version control.

We have configured the build definition’s build number format to follow this pattern. Each time a build is executed, the $(rev:r) notation causes the number to increment. The Version Assemblies task places this number in the AssemblyInfo.cs file. Sports Store is coded to display this version number in its UI.

Build History.png

We can see a history of our builds and their outcomes. The build number is used as a reference.

BuildSummary.png

A summary of the buildis available. We see the test results, code coverage, and any compiler warnings.

Artifacts.png

Here we can see all of the files the build created. This is the artifact that will be used by the release. We can also download this as a ZIP file.

Next, we will discuss unit tests and see what happens in a build when a unit test fails.


Learn More

For details on the topics covered in this article, please visit the links below. You may also download the source code for the DevOps Roadmap Lab on Git Hub. Contact me to set up a free meeting where we can dive deeply into the lab material  and discuss your individual needs.

  • This Article provides a good overview of continuous integration.
  • CI/CD Hello World explains how to implement much of what is covered in this article using a single PowerShell script. There are also a ton of supporting information worth looking into.