TFS Continuous Integration Walk Through Part 2 - Create An Automated Build

This is part of a series of walk throughs exploring CI in TFS, starting from the ground up. The entire series and source code are maintained at this BitBucket repository.
https://bitbucket.org/bladewolf55/tfs-ci-samples

Previous Part: TFS Continuous Integration Walk Through Part 1 - Installing TFS and Checking In a Test Project

Add the Solution to a New Build Definition

References
Build your .NET app for Windows

You can get to the web-based "create new build" wizard a couple of ways.

In the Visual Studio solution, switch to Team Explorer, click the Home icon, then drop down Home and choose Builds.
On the TFS web site (http://[tfs-site]:8080/tfs), select your team project if visible, or click Browse and navigate to it that way. On the project page, open the Build menu and click the plus sign.

Either way gets to the "Create new build definition" wizard. Choose "Visual Studio" and click Next.

Choose the Repository source, in this case the CI Console Sample. We only have one agent queue, the default. Click Create.

This adds a set of build steps to the definition. Click Save and name the definition. Definitions can be used by multiple solutions, so something generic like "Default Visual Studio Build" will work.

Note The Visual Studio Test step will auto-discover many third-party test adapters, including xUnit. It's not necessary to set the path in the step's Advanced > Path to Custom Test Adapters field for this example.

Let's test the build with the default steps. Click "Queue build", the OK.

The build will run in a pretty cool web-based console window. As expected, the unit tests fail.

There's also a summary error message at the end.

BuildConfiguration Default = Release

References
Unit testing on a build server : Release or Debug code?

Notice, above, when we queued the build that we got a dialog letting us set some variables. These variables are part of the build definition, in the Variables tab.

At first, I thought this was a poor choice for a default. And, I do have a concern. But after reading the article referenced above, I realized...

CI Principle
Auto-build your application to the code your customers will be using.

When would building in Release mode be a problem? The first thing I thought of was web.config transforms. What if you have this appSetting in your default web.config...

<appSettings>
  <add key="SysopEmail" value="developers@example.com" />
</appSettings>

and this one in Web.Release.config...

<appSettings>
  <add key="SysopEmail" value="live-support@example.com" xdt:Transform="Replace" xdt:Locator="Match(key)" />
</appSettings>

And, further, you have a method that's being tested that looks like this:

public void SaveCustomer(ICustomer customer) 
{
  var service = new CustomerService();
  try 
  {
    service.Save(customer);
  }
  catch (Exception ex)
  {
    MailService.SendError(ConfigurationManager.AppSettings["SysopEmail"], ex);
  }
}

Now, CustomerService should be mocked, and that should lead to no errors being generated, but "should" has nothing to do with reality. Do we want our CI tests to email our production support on error? No, because they'll think there's a problem in the production system.

There's anything wrong with the method per se. You can argue that settings like this should be in a database. Fine. But until then, what to do?

I don't know. I'm just pointing out that in some cases, the CI build configuration might need to be something other that Release.

Enable and Test Continuous Integration

Let's test that a build will run the next time we commit source code changes. And, let's be a sloppy developer, too.

First, we need to configure the build definition to trigger when we check in. On the TFS site, in the team project, choose the Build menu, select the Default Visual Studio Build, and click Edit.

Open Triggers, check Continuous Integration, leave the defaults, and Save.

Back in our solution, change the TextMan.Greeter method as follows. Note that this will not pass.

    public class TextMan
    {
        public string Greeter(string value)
        {
            return value;
        }
    }

You can run the tests if you want to prove they fail.

Now for the fun. On the TFS web site, go to the team project's Build tab, select the Default Visual Studio Build, and open the Queued view. Keep this page visible if you can. We want to see the build automatically start.

In Team Explorer, click Pending Changes

Enter a comment and click Check In.

Back on the TFS site page, click Refresh and the build should appear.

You can open the build and wait for it to finish (i.e. "fail"). The summary page nicely tells you who authored the last changes.

Our build server is successfully automatically building on check in!

Next Part: TFS Continuous Integration Walk Through Part 3 - Notifications