Continuing on from where I left off, I now move on to discuss the builds themselves.

A build is the term given to the process by which content stored in a code repository is transformed into deliverable artifacts. Most source code is compiled/processed into binary artifacts such as DLLs or EXEs using a known toolset initiated and controlled by a pre-defined build process. Each process usually follows the ‘get latest, build components, run tests and drop build output to deployment folder’ sequence. TFS provides an adequate starter in the shape of the ‘default process’.

Build output can be anything from loose files right up to an installation package. Whilst there is no ‘one size fits all’ answer I would always advocate the provision of an installation package to deploy an application. Using the right technology this can also created as part of the default build process.

Continuing on the branch structure introduced in the last post, there is usually more than one build definition configured (each may also use a distinct process):

• Development branches would typically use Continuous Integration (CI) builds
• Main branch would typically use Nightly builds
• Release branches would typically use Manual builds

Continuous Integration (CI)

CI builds are executed when content is “touched”. The purpose of this build type is that it ensures the quality of code repository content is kept high. For basic implementations the measure of quality may merely reflect how compilable the content is rather than be a measure of its functional quality. However, most CI build systems provide for the execution of tests as part of the build. With an appropriate set of tests, the functional quality of the build can also be measured. A build that compiles but fails testing is likely to be as undesirable as one that fails compilation, perhaps even more so!

TFS 2010 offers a number of different CI build options with one that is possibly still unique: ‘Gated Check-in’. The concept behind this build type is that it operates directly on a check-in. Only when the check-in content builds successfully will the check-in be completed. This is in contrast to most CI builds where the check-in is performed prior to build execution. The advantage of the Gated Check-in is that it’s not possible to check in code that does not compile thus ensuring a higher level of confidence in the stability of the code repository content. A disadvantage is that a single check-in must include all appropriate changes and if the check-in becomes dependent on another it may be impossible to submit a build for successful compilation. In this case I would still advocate the mechanism but allow the build action to be overridden. Different teams have different ways of working so a more standard CI build or a ‘roll-up’ CI build may be chosen instead.

I consider CI build output very transient so the build definition in TFS is set to keep output only from the last few successful.

Nightly

Building the content of the code repository on a nightly basis should be considered the minimum for any project. A nightly build simply provides confidence that the code repository content will support the following day’s code changes. A failed build should be addressed as soon as practicable.

I execute the nightly build against the Main branch as Main is considered stable and it is the baseline for other branches (development and release). Main is updated (merged) with from content from Development branches so code churn is less than that of the source branch. The Development branch content is already considered high quality (it executes Gated Check-in builds with test execution) so any issues should only arise from the result of the merge operation.

Nightly build output is considered worthwhile. I leave the TFS defaults of ‘last 10 successful builds kept’.

Manual

With TFS any build may be executed manually. With both CI and Nightly builds in place there’s less requirement to run a build process manually but the option remains.

However, Release builds are, by comparison to the others described here, executed far less frequently and almost without exception executed manually. A release build will usually have a different process to support the official software release. This may be the in the form of version resource management, code signing of output, release packaging, etc.

Successful release builds are always kept as they form a record of what official releases have been made.

One of the key objectives in investing in this type of build configuration is to minimise the ‘it works when I build it on my machine’ scenarios that are often prevalent in small development teams. Knowing exactly what was included in a release package and how it was generated is key to understanding how situations arise when the application is in front of a customer.

It should be understood that this phase requires a resource that has a good range of experience. Building an application (even a simple one) usually requires an understanding of the software structure, the intended composition and the expected platforms. Whoever is managing this should have ideally been involved in the previous phases on this or other projects so that the task is not performed blind.

The next post will delve into how to configure TFS build ecosystem to support the builds described.

Tags: TFS