Team Foundation Build is part of Team Foundation Server used to automatedly build applications. Typically, such a build gets latest versions of source code and all referenced components, compiles the application, runs tests, creates an installer and so on. It’s also able to log and report build results, assign build number to work items included in the build and much more. Builds can be run manually, as night builds, after every modification and the like.

The purpose of builds is obvious – it verifies that all parts fit together and prepares the application to an executable form so it could be tested or distributed. And because applications are composed of many components (often made by different teams or even companies), the build of all parts in right versions is not a trivial task. It often requires many steps and a lot of time.

Here is the meaning of automation – as soon as the process is automated (and tested), the complicated and error-prone manual work is not needed any more. Time-intensiveness is not a significant problem either, because when automated, a build costs you computing time only while people can engage in work that really calls for a human effort. And without automation, you would never reach sufficiently frequent builds so you may not identify problems soon enough

Because this blog is mostly about Dynamics AX, imagine that you want to prepare a test environment of Dynamics AX. You have to obtain current version of X++ code and (code of) any other components (e.g. external DLL libraries), deploy it (and, depending on AX version, also handle labels, indexes etc.), compile the application, synchronize database, update reports etc. etc. Many steps, a lot of room for mistakes, duration – at least one hour. Automation solves it all and Team Foundation Build provides an ideal infrastructure, although it’s not prepared explicitly for Dynamics AX.

Deployment of Team Foundation Build 2010

Simply put, Team Foundation Build is composed of a build controller that controls the building process and one or more build agents that carry out individual operations. You need at least one build controller and one build agent.

Team Foundation Build can be installed from Team Foundation Server installation medium. If default configuration (one agent, all on a single machine etc.) suits you, it’s enough just to assign a TFS project collection. In a real deployment, you would probably want to do more planning ragarding performance, security, software available to individual build agents and so on.

Build definition is composed of a process template and concrete parameters. The template is based on Windows Workflow Foundation 4.0 – that allows you to easily define the process flow including conditional blocks, loops, parallel processing and so on. Moreover, you can use the graphical editor (see the picture below) and several ways how to create your own building blocks.

Default templates are – understandably – prepared for classic .NET applications – for Dynamics AX or other atypical scenarios, you have to modify a template. Fortunately, that’s something Team Foundation Build count with and possibilities of configuration and extending are very wide.

Usage

Functions related to builds are accessible directly from Team Explorer:

In build definition, you can set basic parameters, e.g. automatic start of builds.

Build Explorer shows planned and executed builds:

You can also display detailed information about each build:

Results can be sent to you by e-mail, you can use prepared reports, a failed build can automatically create a work item for fixing etc. The integration with work items also allows you to track in which build a bug was found or fixed, to analyze which tests should be run for a build, to document content of a build (work items, files) and so on and so on.

Conclusion

Thanks to Team Foundation Build, a build process can be much simpler, more unified and more scalable than if using ad hoc scripts. Process templates based on Windows Workflow Foundation allow to easily modify the whole process and the integration with other parts of TFS offers a range of unique opportunities.

It’s understandable that while adopting Team Foundation Server, emphasis is put on work item tracking and source code management. Even so I find Team Foundation Build rather unfairly neglected. At the same time, development teams waste time with manual builds, writing up changed objects, searching for “where the bug was fixed” and so on, often with rather dismal quality. Team Foundation Build is one of ways how to improve quality and spare time (and money) in the same time.