Team Foundation Server : Build Automation

This article will focus on achieving build automation using TFS.  However, if you want to understand the architecture, configuration, project creation, product backlog, managing SPRINT and releases etc. you can go through these articles

• Understanding Architecture
• Creating TFS Account and Project
• Creating Product Backlog
• Managing SPRINT and releases

All the examples, referred below, use Team Foundation Service (cloud-based TFS).  Some of the settings may be overridden by your TFS Administrator if you are using TFS on-premise (in your organization).

 

What is build automation and do I really need it?

Build automation as the word implies means automating the build process.  But the build automation does not end at compiling your code.  It encompasses several tasks such as

• compiling source code (taken directly from a repository, here TFS)
• packaging into binary code
• running tests (optional)
• deployment of binary code to production environment (optional)

When your team size is small (1-2 developers), you can compile the code on your machine to verify the accuracy of your and probably your team’s code.  But in large teams, it becomes essential that only code checked-in is the code that compiles and quality of code is not compromised.  This indirectly saves time and cost for the organizations.  Build automation allows you to configure set of schedules and processes to ensure that the above objectives are met.  You can have your code built on demand, or schedule it at a particular time (nightly-builds, incremental builds, etc.) or have gated-build to be triggered when any check-in is done.

Scheduled and gated-builds are examples of Continuous Integration (CI)

What build automation does not guarantee?

Bug-free code.  It ensures that your code compiles but does not ensure that your code is bug-free

How do we achieve Build Automation with TFS?

Build automation in TFS is achieved by running automated MSBuild scripts for your projects.  Generation of scripts for most of the common tasks is automated and you need to write script for only uncommon, complex tasks.  So let’s first see how to configure the common tasks

As a first step, you need to connect to a Team Foundation Server.  In this example, I am connected to my CInject repository.  Once you are connected to Team Foundation Server, you can go to your Team Explorer window in Visual Studio.

You can click on Builds and then on New Build Definition

If you do not have sufficient privileges to create build definition, you will get an error message (as below).  You can request your TFS Admin to grant you build rights (ManageBuildResources).

When the New Build Definition dialog opens, follow through these steps.  You need to create this definition once and all your team members will be able to view them.

On the General tab, choose a build definition name.  As a best practice, the build definition name should depict nature of build (nightly, gated), environment and application name

On Trigger tab, you will have following options

• Manual – As the name suggests, you can trigger manual builds on the build server
• Continuous Integration – Trigger a build when code is check-in
• Rolling Builds – Trigger a build at every X minutes
• Gated check-in – Trigger a build before check-in.  This ensures that only error-free code gets checked-in
• Schedule – Schedule a build at a particular time of a day

On Source Settings tab, you can choose the working folders.  It is advisable to choose the closest branch in which the code resides as a working folder.

On Build Defaults tab, you can define your build controller and staging locations

• When using Team Foundation as Service (cloud-based TFS), the build controller will have only one value in the drop down ‘Hosted Build Controller’. When using Team Foundation Server (on-premises), you will have to configure a build controller for yourself.  We will deal with building your own build controller in a separate article.
• For staging locations, you can have the build output checked in to TFS directly or to a shared drive, or ignore the build output. 

  If you are staging it to a shared drive you need to make sure that the Service Account / Active Directory Account through which the build service is running on the build server has Full Control on the shared location

On Process tab, you can define your own build process.  We will deal with the customization of process template in a different article.  When using Team Foundation as Service (cloud-based TFS), you will have following templates

• Default Template
• Upgrade Template – When upgrading from older version of TFS
• Azure Continuous Deployment – Build and deploy websites and services to Azure Cloud platform. Read more
• Tfvc Template – Team Foundation Version Control template
• Git Template – GIT version control template

Each template will give you different options to configure.  Some of the common options are

• Version Control - Clean Workspace, Get Version, Label Sources
• Build –
• Projects - You can select solution file or individual projects that need to be built
• Configurations – You can select a configuration and platform here.  The configuration selected here should be available under Configuration Manager of your solution otherwise the build will fail.  This can also be useful when you have configuration transforms for app.config / web.config files
• Output Location – In TFS 2010, the build output of all the selected projects was always copied to a single folder.  With TFS 2012+, you can choose of the options - single folder, per project, or as configured in individual projects.
• Advanced – This setting allows you to pass additional parameters to MSBuild, configure pre-build and post-build scripts and enable/disable code analysis.  For the uncommon complex tasks you can check-in your pre-build and post-build scripts in TFS and change the settings in Advanced section.  You can also choose to run FxCop to perform code analysis on your projects
• Test – You can configure your test projects here.  By default, MSTest will be used as engine for unit-testing.  If you want to disable unit-test runs, you can set Disable Tests to true
• Advanced -  Advanced allows you to configure your build agents and post-build behaviour. If you want to create a Build Bug for every failed build, or want to update Work Items with the build number, you can set it up in this setting

On Retention Policy tab, you can define how long you would want to retain build outcome. In your organization, this may be driven by some audit/compliance requirements or by best practices.

Once you have configured the build definition, you can view the build definitions in the same Team Explorer

You can Queue New Build, Edit Build Definition or even View Controller Queue from Team Explorer.  Any on-going build will be visible under ‘My Builds’.  You can double click on an on-going build to view its status.  With large teams, you can use Build Notifications tool that minimizes itself to system tray and pops-up with build notifications such as Build Triggered, Started, Completed, Failed.  This is very handy specially when you have large teams spread across geographies.

Hope this helps in understanding the process of creating a build with TFS.