Inside TFS

A Primer on Microsoft Build Automation

If you've got a strong version-control system, implementing an automated build process is the next logical step.

• By Mickey Gousset
• 03/15/2012

Everyone wants to improve the quality of the software they build. One way to accomplish that goal is to implement a strong version-control system. The next step is to implement an automated build process.

One of the problems with software development is that you usually don’t see the product until it is in a finished state. The problem with this approach: how can you show progress to a customer? Being able to show the customer a running piece of software is a good way for them to know how things are going with the development effort, and for you to gauge your progress. Agile methodologies such as Scrum embrace this idea; at the end of each sprint, you have a functioning piece of software.

In theory, showing your customer a working version of your application seems like a good idea. In reality, it can be a complex task to accomplish. The problem is, assembling a working piece of software can take time, time that could be spent on other project tasks. So ideally, you want to be able to automate this build process, allowing you to both show progress and incorporate feedback from project stakeholders.

More Than Compiling Code
Build automation is the ability to assemble your application into a usable product with a simple, single action. Usually, build automation includes not just compiling the source code into binaries, but also running tests, creating documentation, and deploying the compiled code for manual testing.

Automating the build process takes some of the potential for errors out of the process. Most software applications are very complex, and manually building the software can take one or more full-time individuals. Even these individuals can get it wrong sometimes. Being able to automate your builds can stop errors from happening.

Developers in Visual Studio 2010 can run their applications by pressing F5. This compiles the code on the local workstation and runs it. However, it doesn’t ensure that the code works with the latest code from other developers on the project. It also doesn’t allow for running automated tests.

A build automation server makes it easy to compile the entire application, almost as easy as a developer pressing F5. The build automation server looks for changes in version control and automatically builds the project using the latest code in the version-control system. Usually, builds can be kicked off manually, on a timed schedule, or even on every check-in (this is known as continuous integration).

Scripting the Build
Before you can automate your build process, you need to script out the build so it can be executed with a single command. With Team Foundation Server, this is done using both MSBuild and Windows Workflow Foundation (WF). MSBuild is the build system used by Visual Studio and is part of the .NET Framework. Windows Workflow Foundation is a programming framework from Microsoft used for defining and executing workflows. Team Foundation Server makes use of both of these languages to automate the build process.

Once you have scripted the build process, the next step is to run it on a schedule. This helps remove yet another manual step from the process. Running the build on a separate build server also helps remove a developer’s machine from the equation, ensuring that all dependencies are accounted for in the application.

Team Foundation Server has provided build automation capabilities since TFS 2005. This process is referred to as Team Foundation Build. In TFS 2005, it was built heavily around MSBuild, but was rather limited. TFS 2008 offered many improvements to the build process, including multiple triggers for builds. TFS 2010 moved the build automation process to use WF as the primary engine.

While Team Foundation Build can only be used with TFS Version Control, you derive many benefits from this integration. Team Foundation Build can easily access information from version control, as well as the work item tracking system. And the reporting capabilities provided by TFS offer detailed information on the status of your builds.

Build automation is very important to your application lifecycle management, and Team Foundation Server provides some nice features around build automation. If you are serious about the quality of software you deliver, then you need to be serious about build automation.