Home             About Us             Sign Guest Book             Contact Us             Subscribe              RSS  
SQL
Articles
Tools
Code Snippets
Links
Tips & Tricks
FAQ
Resources
.NET
Articles
Code Snippets
Links
FAQ
Resources

Blogs
Saravana Kumar
Vinod Kumar

Newsletter

Click on the image to subscribe to our Monthly Newsletter.

Click here for Archives

Expert Chat
No Chats Available

Automating build Using Team Build 

Every software development project requires a proper build process for delivering a quality product. The build process generally involves the following steps:

  1. Getting the source code of the whole application
  2. Building the whole application
  3. Validating the build by running automated tests 
  4. Reporting and releasing the build.

Generally, the build process involves many repetitive and time consuming manual steps. Automating these steps not only reduces time and resource utilization but also helps to implement other processes like Continuous Integration, nightly or daily builds. By this, you can always ensure a stable product at any point of time during the development.

Though there are many external products/tools for automating build process, till date, there isn’t any build tool from Microsoft. Usually programmers create scripts for automating various steps involved in the build process. However, with Visual Studio Team System [VSTS], Microsoft has released a new build automation tool called Team Build.

This article explores this new build automation tool from Microsoft and it explains how to use Team Build scripts to implement other processes, like nightly build and continuous integration.

VSTS Team Build

VSTS Team build is built on top of MSBuild. MSBuild is the new build platform released by Microsoft along with .NET Framework 2.0. Team Build internally uses MSBuild for building the source code.

For more details about MSBuild, refer this link:

http://channel9.msdn.com/wiki/default.aspx/MSBuild.HomePage

VSTS Team Build integrates with various tools available in VSTS like Source Control Management, Work Item Tracking, Reporting and Testing tools. The first step in automating build process is creating a build script. VSTS Team Build provides a wizard for creating build scripts. Before you start working on VSTS Team Build, you need to have Visual Studio Team System Client installed on your machine.

To create a build script, open Team Explorer in Visual Studio Team System. Then select the project in team explorer for which you wish to create the build script. In the Team build section of that project, right click and choose “New build type..” option from the menu. Team build script creation wizard will popup, as shown in following figure.

Build script wizard will walk you through the following steps:

1. Selection.

In this step, by default, the team build provides a list of all the solution files checked into the source control for the current project. You can select the required solutions files for building.

Note: In Visual Studio, the solution file is used as a container file for holding related projects and its artifacts like source files, configuration files, etc.

2. Configuration

You can specify the configuration for your build here. For example, a simple configuration would be to specify whether it is a release or a debug build.

3. Location

Here, you will configure the build machine name, the location where you want to get the source files from, before the build and the location where the binaries will be placed after the build is successful.

4. Options

Here, you will specify the list of automated test that you want to run during build process. Build will be successful only when each automated test passes. You can also specify whether you want to perform the code analysis along with your test.

Team Build wizard creates a build script once all the above steps are completed. This script is an MSBuild Script which will be used by MSBuild Engine for building the whole application. A sample Team build (MSBuild) script is shown in Figure 2 .

<?xml version="1.0" encoding="utf-8"?>

<Project DefaultTargets="DesktopBuild"     xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Import   Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

  <ProjectExtensions>

    <Description>

    </Description>

    <BuildMachine>neon</BuildMachine>

  </ProjectExtensions>

  <PropertyGroup>

    <TeamProject>PV-6</TeamProject>

    <BuildDirectoryPath>c:\saravana\buildsource</BuildDirectoryPath>

    <DropLocation>\\xeon\binaries</DropLocation>

    <RunTest>false</RunTest>

    <WorkItemFieldValues>Priority=1;Severity=1</WorkItemFieldValues> 

    <RunCodeAnalysis>Never</RunCodeAnalysis>   

    <UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>

  </PropertyGroup>

  <ItemGroup>   

    <SolutionToBuild Include="$(SolutionRoot)\SampleWindowsApp\SampleWindowsApp.sln" />

  </ItemGroup>

  <ItemGroup>   

    <ConfigurationToBuild Include="Release|Any CPU">

      <FlavorToBuild>Release</FlavorToBuild>

      <PlatformToBuild>Any CPU</PlatformToBuild>

    </ConfigurationToBuild>

  </ItemGroup>

  <ItemGroup>   

    <MetaDataFile Include="$(SolutionRoot)\SampleWindowsApp\SampleWindowsApp.vsmdi">

      <TestList> </TestList>

    </MetaDataFile>

  </ItemGroup>

  <ItemGroup>   

  </ItemGroup>

</Project>

Team Build Architecture

A pictorial representation of the Team Build architecture is shown in following figure.

Team Build architecture starts with the Team Foundation client from where the user will connect to Team Foundation and create a build script.

Note: Team Foundation is the server side component of Visual Studio Team System.

The build script is stored in the Team Foundation server. The Team Foundation server consists of two tiers. The Application Tier is where all the services like source control management service, build service, work item tracking service and other services reside. In Data Tier, all the data of these Team Foundation services are stored.

Team Build provides an option for a dedicated build server other than the Team Foundation server. In most of the software development projects, there will be a dedicated server for build. To support that process, team build also provides an option to install team build components on a separate machine. To know more about how to set up Team build server, refer the “Setting up the Build Server” section of this article. These build server components can also be deployed along with the Team Foundation server.

When the build is started from Team Foundation client, a call is made to the Team Foundation server and from there the build information is sent to the build server. Build server takes the build script from Team Foundation client and does the following job based on build script configurations.

  1. Gets the source code from Team Foundation source control management. From the configuration file, build server recognizes the solution files that need to be picked up from the source control management for building.
  2. Uses MSBuild engine to build the source code
  3. Uses source control management to label the source code with the current build number.
  4. If the build succeeds, Team build runs the tests specified in the build script to validate the build.
  5. If the build fails, Team Build automatically creates a bug work item and attaches the build information to the work item.
  6. Generates the reports for the build. Despite the failure or success of the build, the report is generated.
  7. If the build tasks succeed, Team Build places all the binary files of the build in a network share location as specified in the Build scripts.
  8. In the final step, Team Build will send the notifications to all the subscribers. You can subscribe to build events as described in the following section.

Subscribing to Build Events

By default, Team Foundation provides the following events notifications.

  1. Build status change Event

This event is fired whenever the build status is changed, build statuses are - pass, fail and stop.

  1. Build Success Event

This event is fired only when the build passes.

Based on your requirement, you can subscribe to these events. To subscribe to these events, open the team explorer and select the current project and choose Project Alerts option from Team menu in Visual Studio Team System.

In the project alerts window, you can see a list of events which you can subscribe. In this window, specify your email address and subscribe to the required event. Once the event is raised, you will receive a mail that contains an hyperlink which takes you to the report of that build.

Build the application

Once you create the Team build script using team build wizard, it is automatically stored in the Team Foundation server. You can view/edit the team build script from Team Builds section in Team Explorer window for a project. When you want to build that project, you can select the build script in team explorer window and build it from there.

The only drawback with this approach is that, you can’t automate the build process i.e. whenever you want to build your application, you will need to manually open Visual Studio Team system and run the build from team explorer.

Though VSTS Team build doesn’t provide direct support for running build scripts automatically, there are a few workaround for automating build script execution.

There are two types of requirements for automating the build process:

  • You might want to run the build script at a certain time. Build process like daily, nightly or weekly build comes under this category. These are called timely builds.
  • You might want to run the build script when somebody checks in some code in the source control management. This process is called continuous integration.

In the next few sections, we will see how to implement both these type of automation.

Timely Build

VSTS provides a command line utility TFSBuild.exe for running the build from command line. This command line utility is placed in the following location,

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE

You can specify the foundation server name, build script name, project name and few other build related details as parameters to this utility. When you run it, it will give you the status report of the build in the command prompt as shown in the following figure.

You can use this command line utility to schedule the timely build. For scheduling, you need to use Windows OS scheduler feature. Using this option, you can schedule an application to run at any time.

Note: To access Windows Scheduler, Go to All Programs à Accessories à System Tools à Scheduled Tasks.

Continuous Integration

The next automated build requirement is continuous integration. Continuous integration is the strategy of making sure that changes to the project’s code base are built, tested and reported as soon as they are introduced. To know more about the process and benefits of continuous integration, check out this article by Martin Fowler,

http://martinfowler.com/articles/continuousIntegration.html

Using our earlier automated approach, we can’t do continuous integration as we don’t know when the developer will check in the code. So we need some mechanism to identify the check in events.

Fortunately, VSTS Source Control Management services provides Check-In event which is similar to our Build Success Event which we have seen earlier. To get an event, we need to subscribe to that event. There are two types of subscriptions for all VSTS events:

1. Email notification subscription which we have seen previously when we dealt with Build Completion Event

2. Second type of event subscription is web service subscription i.e. when the event is raised in VSTS, TFS will call a method in a web service with that event information. We set the webservice location while subscribing for the event.

We can use the later option to implement continuous integration with VSTS, i.e. whenever a check-in happens; an event is fired by source control management service. During that time, notification will be sent to the subscribed web service. In this web service, we need to write the code for running the build script.

The next step is how to run the build script programmatically. It is not a recommended approach to run the build script programmatically using command line utility from web service. The only option we have is to use the build service provided by VSTS.

There are two types of build service available in Team build.

  1. BuildController Service

This service is used to control the build script execution. Using this script, you can run, stop and delete the build script.

  1. BuildStore Service

Using this service, you can monitor the build status or you can view the previous build results.

For implementing Continuous integration, we need to use the BuildController Service. The code for running the build script programmatically is shown in the following code snippet.

[SoapDocumentMethod("http://Microsoft.VisualStudio.Bis/Notify",

     RequestNamespace = "http://Microsoft.VisualStudio.Bis")]

    [WebMethod]

    public void Notify(string eventXml, string tfsIdentityXml)

    {

        BuildController.BuildController buildCtrl = new BuildController.BuildController();

        BuildParameters buildParam = new BuildParameters();

        // I have hard coded the values for foundation server, project and build type here.

        // You can alter this to pick these values from database or config files.

 

        buildParam.TeamFoundationServer = "http://XEON:8080";

        buildParam.TeamProject = "PV-6";

        buildParam.BuildType ="BuildScript";

        buildParam.BuildDirectory = @"c:\Saravana\buildsource";

        buildParam.BuildMachine ="Neon";

        buildParam.DropLocation =@"\\xeon\binaries";             

        buildCtrl.Credentials = System.Net.CredentialCache.DefaultCredentials;       

        string buildUri = buildCtrl.StartBuild(buildParam);      

}

If you look at the above code, you see that we need to create the instance of buildcontroller service, pass buildparameters, and then run the build script by calling the StartBuild method in build controller service. You can write your custom code after you start the build. For example, you might want to send a mail to your project manager about the build or you can create a work item in case the build fails.

The method name in this web service needs to be Notify. Once you subscribe to Check-in events, this method is called when the check-in event fires. For subscribing to check-in event, we need to use a utility BisSubscribe.exe available in the following location.

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

Parameter required for this command line utility are,

Bissubscribe /eventType CheckinEvent /address http:////16.138.29.206/BuildService/continuousIntegration.asmx  /deliveryType Soap /userId domainname\username /domain http://teamfoundationame:portnumber

Run this utility to subscribe to the check-in event. You will be specifying the web service name during subscription, so VSTS Eventing Service will call this web service when Check-In Event fire.

Setting up the Build Server

As seen earlier, VSTS Team build provides an option to have a dedicated build server. To provide this option, Team build components are provided separately in Visual Studio Team Server installation script. You can find the Team build component in a separate folder named bb. To install team build component, run the setup.exe in that folder.

To verify whether team build is installed in the build server, look for TeamBuild service in services console window of the Window OS.

Summary

Continuous Integration is one of the key processes in Extreme Programming (XP) methodology. This process is getting adapted widely in all kinds of software development projects. With tools like VSTS Team Build, this process can be implemented very easily. If at all, you feel continuous integration might be an overhead in your development, then you should at least switch to timely build process, like daily build or nightly build.

Comment about this article
Free Hit Counters
Free Hit Counters 		Copyright © 2000-2003 ExtremeExperts.com, Terms of Use Best viewed on 1024x768 using Microsoft Internet Explorer 5.5 and later. Hosted on Windows Server 2003/.NET Framework 1.1.