Pages

Sunday, February 5, 2017

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


ci-logo
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.

  1. In the Visual Studio solution, switch to Team Explorer, click the Home icon, then drop down Home and choose Builds.
     2017-01-31_101042
  2. 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.
     2017-01-31_102849

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

2017-01-31_102926

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

2017-01-31_103317

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.

2017-01-31_103740

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

2017-01-31_104047

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

2017-01-31_104540

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

2017-01-31_104648

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.

2017-01-31_104700

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.

2017-01-31_110712

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

2017-01-31_110924

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.

2017-01-31_105424

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.

2017-01-31_105936

In Team Explorer, click Pending Changes

2017-01-31_105614

Enter a comment and click Check In.

2017-01-31_110109

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

2017-01-31_111112

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.

2017-01-31_111405

Our build server is successfully automatically building on check in!

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

No comments:

Post a Comment