Update: with Team Build 2013 you can even pass parameters to queued builds.

I have seen several Team Foundation Server environments where multiple build definitions exist in a single project and need to executed in a particular order. Two common techniques to achieve this are:

• Queue all the builds immediately and rely upon using a single build agent to serialize the builds. This approach prevents parallelization for improved build times and continues to build subsequent builds even when one fails.
• Check build artifact(s) into source control at the end of the build and let this trigger subsequent builds configured for Continuous Integration. This approach can complicate build definition workspaces and committing build artifacts to the same repository as code is not generally recommended.

As an alternative I have developed a simple customization to TFS 2010’s default build process template (the DefaultTemplate.xaml file in the BuildProcessTemplates source control folder) that allows a build definition to specify the names of subsequent builds to queue upon success. It only requires two minor changes to the Xaml file. The first is a line inserted immediately before the closing </x:Members> element near the top of the file:

    <x:Property Name="BuildChain" Type="InArgument(s:String[])" />

The second is a block inserted immediately before the final closing </Sequence> at the end of the file

    <If Condition="[BuildChain IsNot Nothing AndAlso BuildChain.Length &gt; 0]" DisplayName="If BuildChain defined">
      <If.Then>
        <If Condition="[BuildDetail.CompilationStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded]" DisplayName="If this build succeeded">
          <If.Then>
            <Sequence>
              <Sequence.Variables>
                <Variable x:TypeArguments="mtbc:IBuildServer" Default="[BuildDetail.BuildDefinition.BuildServer]" Name="BuildServer" />
              </Sequence.Variables>
              <ForEach x:TypeArguments="x:String" DisplayName="For Each build in BuildChain" Values="[BuildChain]">
                <ActivityAction x:TypeArguments="x:String">
                  <ActivityAction.Argument>
                    <DelegateInArgument x:TypeArguments="x:String" Name="buildChainItem" />
                  </ActivityAction.Argument>
                  <Sequence DisplayName="Queue chained build">
                    <Sequence.Variables>
                      <Variable Name="ChainedBuildDefinition" x:TypeArguments="mtbc:IBuildDefinition" Default="[BuildServer.GetBuildDefinition(BuildDetail.TeamProject, buildChainItem)]"/>
                      <Variable  Name="QueuedChainedBuild" x:TypeArguments="mtbc:IQueuedBuild" Default="[BuildServer.QueueBuild(ChainedBuildDefinition)]"/>
                    </Sequence.Variables>
                    <mtbwa:WriteBuildMessage Message="[String.Format(&quot;Queued chained build '{0}'&quot;, buildChainItem)]" Importance="[Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High]" />
                  </Sequence>
                </ActivityAction>
              </ForEach>
            </Sequence>
          </If.Then>
        </If>
      </If.Then>
    </If>

You can see the resulting DefaultTemplate.xaml file here. After applying these changes and checking-in the build process template file you can specify which builds to queue upon success via the Edit Build Definition windows in Visual Studio:

You can specify the names of multiple Build Definitions from the same Team Project each on a separate line. When the first build completes successfully, all builds listed in the BuildChain property will then be queued in parallel and processed by the available Build Agents. No checking is currently done for circular dependencies so be careful not to chain a build to itself directly or indirectly and create an endless loop.

I like to set the “Treat warnings as errors” option in all my Visual Studio projects to “All” to ensure that the code stays as clean and maintainable as possible and issues that may not be noticed until runtime are instead discovered at compile time. However, on existing projects with a large number of compiler warnings already present in the code base, turning this option on will immediately fail all the CI builds and either create a lot of work for the team before the builds are passing again or the team will start ignoring the failed builds. Neither is a desirable situation.

On the other hand, unless someone is actively monitoring the warnings and notifying the team when new compile warnings are introduced, the technical debt is just going to increase. To address this I thought it would be useful to extend the default build process template in TFS 2010 to compare the current build’s warning count with the warning count from the previous build and fail the build if the number of warnings has increased. The Xaml required for this can be found here. Hopefully this strategy will result in the team slowly decreasing the warning count down to zero and then the “Treat warnings as errors” option can be enabled to prevent new compiler warnings being introduced to the code base.

At the moment this is a very naive implementation – if an increase in warnings fails one build, subsequent builds will pass unless the warning count increases again. I have two ideas for improving this:

1. Compare the current warning count against the minimum warning count of all previous builds.
2. Fail if the minimum warning count has not decreased within a specified time period (eg two weeks).

If I implement either of these two ideas, I’ll update this post but they should both be quite easy to do-it-yourself.

Microsoft Test Manager in Team Foundation Server 2010 enables users to mark a lab environment as “in use” with their name, time stamp, and a comment.

Other people can then see this and contact the user first if they’d also like to test, redeploy or otherwise interrupt a lab environment.

However, if a user manually queues a Lab build from Visual Studio Team Explorer, or a Lab build is triggered by a schedule or a check-in, this marker is not visible and the Lab build will execute, redeploying the environment and most likely upsetting the user who was already using the environment.

As a solution to this, I have modified the default lab build process template to include a new parameter to specify whether the build should fail if the environment has been marked as “in use”.

Thankfully, most of the hard work has already been done in the form of the out-of-the-box Workflow activities for Lab Management, and I just needed to add a small chunk of XAML to the existing LabDefaultTemplate.xaml file in my Team Project’s “BuildProcessTemplates” source control folder. The full customised template is here, but the core of the change was this simple code:

And now the lab build will fail when the environment is marked “in use”…

There are a few articles describing how to configure your Team Foundation Server to be accessible externally. These articles focus on exposing the TFS web services, the SharePoint team project portals, Reporting Services, Team System Web Access and, in TFS 2010, even Lab Management, via public HTTP(S) urls.

The primary TFS resource omitted from such articles is how to expose the build outputs externally too, so that clicking the Open Drop Folder and View Log File links in the Visual Studio Build Explorer just work wherever you are.

My solution is based on the feature of modern versions of Windows (ie XP and later) to automatically try WebDAV when the standard file share protocol (SMB/CIFS) fails to connect to a given UNC path. Simply, you configure a WebDAV URI (using the IIS 7.5 WebDAV module in my case) that corresponds directly to the file share UNC used for build drops. That is, if your build drop path is \\myserver\myshare\ then the WebDAV URI must be http://myserver/myshare/.

While build drops can be hosted on any file server, I usually see the Team Foundation server itself, or even the build agents used as the location for the drop share. Having the WebDAV server and the drop file server as the same machine simplifies the setup (for the reasons below) but installing WebDAV on your build agent just complicates a build environment that should be kept as clean as possible, so I’d recommend against using the agent for the drop location. In my case I opted for a dedicated build drop file server, but you can just as easily use the TFS server if your infrastructure resources are limited.

When configuring the WebDAV module for HTTP we use Windows Authentication for granting access and this works great for resources on the WebDAV server. However, from my experience*, if the WebDAV site itself, or a virtual subdirectory, is mapped to a remote file share, impersonation of the credentials provided by Windows Authentication fails. If you switch to Basic Authentication though, access to resources not local to the WebDAV server then works, but Basic Authentication has its own problems.

With Basic Authentication, the user’s password is sent over the wire, so WebDAV refuses to allow it by default unless you also use SSL. Sadly, the Windows WebDAV redirector won’t automatically try HTTPS for UNC paths unless the server name is suffixed with “@ssl” (eg \\myserver@ssl\myshare\) and this unfortunately forces WebDAV to be used even when internal systems do have direct access to the file share.

Another small catch with using WebDAV to expose drop folders is that they often contain “web.config” files and IIS naturally tries to parse these files typically breaking the ability to browser to those folders. The solution I found from Steve Schofield was to set the “enableConfigurationOverride” property to “false” for the Application Pool used by the WebDAV IIS Site. This property isn’t available via the Management Console so you’ll have to use “appcmd” or edit the “applicationHost.config” file directly.

Update: With Windows 7 or Vista, a registry change is also required to add the WebDAV server’s FQDN to a list of servers to forward credentials to. It’s all documented in the Microsoft KB article 943280.

Finally, to complete the seamless experience, the drop file server should be referenced by the same fully-qualified domain name (FQDN) both internally and externally (eg \\myserver.mydomain.com\myshare\). The first step for this is to ensure that the drop file server itself will authenticate via the FQDN locally, especially if it’s the TFS server. This is done by adding the FQDN to the server’s BackConnectionHostNames registry key. Secondly, ensure that the FQDN resolves correctly for both internal and external users. In my case I configured Split DNS to resolve the FQDN to an internal IP address for internal users and a public IP for the public, keeping the routes as short as possible.

You can now change your build definitions to use the FQDN UNC as the default drop location and all future build outputs should be reachable via the same path wherever you are.

*It may be possible to get Windows Authentication impersonation to work for resources not hosted on the WebDAV server by granting the correct delegation permissions but I would need to do more research.

When you create a new Team Foundation Server 2010 Team Project from the standard MSF process templates and choose the defaults, you will be given a BuildProcessTemplates folder in your new project’s source control root. In this folder you should discover three Xaml files, corresponding to each of the out-of-the-box build types: default, 2008-compatible build, and Lab build.

If you then create a new Build Definition for your team, the Process page will default to the “Default Template”. If you expand for more details, you’ll see a drop-down of the three choices or a New button. It’s not until you click the New button that it’s obvious you can still put your build files anywhere in source control, just like TFS 2008. Upon creating a new process file you should also discover the drop-down list will include your new file, even if you don’t store it in BuildProcessTemplates folder.

Until your build definitions exceed the limitations of the out-of-the-box process files, it is often fine to use them where they are and just adjust the Parameters property grid. As soon as you want to customise the build process itself, you should move to a more manageable arrangement for these files. My preferred structure is basically to create a new Builds folder under your Trunk folder (or “Main” or whatever you call your branching root) and then branch the base template file (eg DefaultTemplate.xaml) into this new Builds folder with a more descriptive file name (eg MyNightlyBuild.xaml) and customise it there.

Unfortunately, while the Build Definition window has a Copy button to create a new process file to work on in a single step, copying doesn’t maintain a relationship between your new file and the original. This is important because now in 2010, the build files contain the full build process (not just the overrides like TfsBuild.proj files did) and they therefore much more closely resemble the Microsoft.TeamFoundation.Builds.targets file from TFS 2008 and are subject to servicing. By branching, when a service pack introduces new versions of the templates, you will be able to merge the updates through to your customised files. And just like the 2008 targets files, you should avoid reverse-integrating your customisations back to the originals.

In addition to leaving the original files unchanged, there are other reasons why you should put your process files in a Build folder below your trunk:

• When you branch source, you should branch build process too. Keeping them below your branching root makes this automatic.
• If you want to use reference custom build activities, you can no longer just double-click the Xaml file in Source Control to edit it. Instead you need to put your Xaml file in a project that has project references to the activity assemblies. The build folder gives you a perfect place to put the project file and optionally add it to your solution.
• Finally, customised builds will often reference other external files (eg PowerShell scripts) and the build folder is a good place for them too.

If you’ve found any other good practices with managing TFS 2010 build process files, feel free to leave a comment.