Nearing the end of my posts regarding builds, this one describes a TFS build definition.

If you’ve read the previous articles you will know that I consider TFS to have an excellent build eco-system. Other application suites offer similar services but somehow TFS manages to do exactly what’s expected with the minimum of hassle. Whilst many of the concepts are technology agnostic please be warned I’ll be using TFS as my reference point.

I’d first like to touch on how Visual Studio solution (.sln) files are typically used as it has an impact on how each build definition may be configured. Microsoft’s ‘guidance‘ is that everyone should work with a large solution file and it is that that is added as the component build item. This has some advantages:

• the developers always build all of the software to the extent as controlled by the solution file
• the solution file will define the build order using project dependencies so this need not be understood by everyone
• changes to the build order made in a solution are immediately reflected in the next build

Potential drawbacks are that:

• all developers will always have to pull out the latest source and build all components in order to start a task – if the task is small this could use a significant portion of the task’s allocated time
• Visual Studio solutions files with large amounts of projects are [still] slow – even after the improvements Microsoft has made in Visual Studio 2010
• changes to the solution must be carefully considered and controlled – build output may be affected
• finally, as all components are built on each developer workstation, all developers will typically need a full set of licensed controls even though their daily task output has no need for them thus increasing the potential cost and servicing impact

What’s my advice? Consider the options before choosing to use large solution files and if you can, don’t use them.

I practise a “work against the latest nightly build and only get the minimum code out to complete the feature” development style. All developers will be required to know the system composition so that projects may be built individually in the correct order. However, knowledge such as this being shared across the team should be considered beneficial to the ongoing project rather than detrimental.

A TFS build definition consists of the following major attribute groups:

• When – The choice of trigger (Manual, CI, Scheduled, etc. all covered in the last post)
• How – Build process template and associated configuration
• What – Location of what to monitor; list of components to build

TFS provides a default build process template that performs standard actions suitable for out of the box build operation. It’s normal to customise this process to suit the needs of the project. Additional actions may include resource version number updating, code signing binary output, etc. As the TFS build process template is built using Microsoft Workflow it’s extremely easy to customize.

Other aspects of ‘How’ include whether tests are executed, the build configuration type, source and symbol server integration, etc. These are fairly self explanatory and exposed in the build definition editor using simple UI options.

There are 2 aspects to ‘What’ is built:

1. the location of the source code repository that the build definition will work against – typically the root of a branch
2. the complete set of components that will be built from that location

With a single large solution file in use, the build definition will refer to it alone. If individual project files are used, the build definition will be more complex referring to the project file for each component in an appropriate order.

Whilst it’s not a difficult task to configure a build definition I would advocate the use of an assigned resource, a “build engineer” if you will, so that at least the responsibility lies with someone. This role can be shared with a developer or be completely separate depending on the size/structure of the company/product build requirement.

With TFS, builds are remotely executed on Build Agents that are managed by Build Controllers. There are typically many Agents to a single Controller and a single Controller per TFS Team Collection. As the product is highly configurable it could equally be multiple Controllers each with a single Agent. Whilst there is no right or wrong configuration the former provides a pattern that is probably better understood.

Each Build Agent uses a distinct working folder thus allowing for multiple builds to be running under different Agents on the same machine. Custom Tags are used to define a Build Agent that is configured for specific build duties, such as being hosted on a platform with a particular configuration. A build definition can use these tags to indicate to the Build Controller what type of Build Agent is required. Builds are then scheduled on the next available Agent that matches the Tag criteria. Should no Agent exist or be available the build will fail. A build definition that specifies no Tags will be scheduled on any Agent.

With the correct build definitions in place, the following key drivers for using any form of automated build should be realised:

• Traceability
• Repeatability
• Reliability

Execution of builds remotely means that the code is taken from the developer [as part of a Check-in] and built within the confines of the controlled build eco-system using one of the pre-defined build processes. The oft abused “it works on my machine” issue is minimised as builds are not performed on a developer’s machine where a potentially variable set of control and runtime versions may have yielded unpredictable results. Code contained in each and every build is also only ever taken from the content of a TFS branch (development/main/release) and is therefore fully traceable.

Build status reporting is via e-mail, desktop notification application or custom event subscription. Completed builds can then be assigned a quality indicator that may be used further in the development process.

After a very short time frame it’ll be hard to imagine returning to the ways of old!

Most developers will perceive running a build as the execution of Visual Studio in much the same way as a local build action is performed. It is also true that most small development teams simply install a full development environment on the Build Agent and queue builds using it and depending on the project type, that actually may be necessary. As I believe there is a better way of achieving the same result, that will be the subject of my next post.

Tags: TFS, Visual Studio