The Team Build facility in Team Foundation Server allows development teams, and in particular configuration managers to define a build that can be performed on a remote server at the click of a button. After the build is complete the results of that build process are uploaded to a drop location on a network volume somewhere.

Builds that are performed can quite often be rejected because of a failure caused by a file not being checked in, or some debug-time setting propogating into a build destined for release. Other builds may be rejected at a later date due to functional testing identifying a problem.

While recording details about each build that is performed is useful from an auditing perspective, storing the actual artefacts from that build does come at a cost – a storage cost. The solution is to regularly clean the old rejected builds out of the drop folder to reclaim space.

At Readify we try to run a pretty tight ship when it comes to Team Foundation Server. So not just anybody can go in and delete files from the drop location – that might remove good builds that may be required for diagnostics later on down the track. But how do we allow people clean-out the garbage?

Introducing the Build Clean-up Service

This is an extension to Team Foundation Server that I’ve had queued up to develop for quite some time. The clean-up service takes care of cleaning out the “Rejected” and “Unexamined” builds after a specified period of time (configurable).

After installing and starting the build clean-up service a few things happens. First, the “WorkItemStore” is contacted to get a list of Team Projects defined within Team Foundation Server, then a list of builds performed under that scope of that Team Project is retrieved from the “BuildStore”.

Each of the builds is checked in turn to determine whether it is a candidate for clean-up. The rules for determining this are as follows:

• Has the expiry date for the build been reached? This is a basic calculation to determine whether time since the build was finished is greater than the expiry time span defined in the configuration file. Currently ours is set to fifteen days.
• Does the drop location exist? This feature was added after I realised that during the installation of our Team Foundation Server I had tested out some builds and subsequently deleted them off the file system – this will be a pretty common scenario I think.
• Has the build actually completed? If you set quite a low expiry time span and you happened to have a fairly long build process its concievable that the service could kick in and start trying to delete the build while it was still running. So here we make sure we are only considering whether a build is a candidate for clean-up checks for this.
• Has the build been abandoned? Abandoned build are builds that are either in a Rejected or Unexamined state. By default all builds go into an Unexamined state, but remember that the build needs to have expired as well before it gets cleaned-up so you shouldn’t have good builds going missing before you have a chance to inspect them unless you set a really low processing interval on the service (default is one hour).

Once it has been determined that a build is a candidate for clean-up the service systematically deletes the build artefacts in each of the specified build locations. There are a few things that it doesn’t touch however. The clean-up service will not delete the build log (provided it is called BuildLog.txt) and it will wrote a “Readme.txt” file to explain what happened to the files.

In addition to that, two entries will be placed in the event log, one for the start, and one for the completion of the clean-up for each build. This provides an audit trail that monitoring software can pick up if you require that level of control.

Downloading and Installing the Build Clean-up Service

Before you download, install and run the build clean-up service I want to let you know that I take no responsibility for what this does to your system. It was tested on my laptop and a live Team Foundation Server environment but I can’t guarantee that I’ve picked up every issue. I recommend that you take a backup of your drop locations prior to installing and running this service – just in case, and I would warn development teams that it is being turned on. That said – I’m pretty sure that it’ll work for you.

The first thing that you need to do is download and unzip the service onto a machine that has Team Foundation Server components installed on it. I would recommend either the application tier or the team build server (if you have those components distributed). After that you need to use the .NET Framework (2.0) installation utility to register the service on the computer:

InstallUtil.exe BuildCleanup.exe

During the installation process it will prompt for credentials for the service. One sure fire way to make sure it has the right credentials is to make it run under the same service account as the Team Build service, on most systems thats [DOMAIN]\TFSBUILD.

The final step is to edit the BuildCleanup.exe.config configuration file to point the service at the URL for your Team Foundation Server. Once that is done you should be able to start the service by issuing the following command:

net start BuildCleanupService

When the service springs to life you’ll probably get a flurry of activity, depending on how long your Rejected and Unexamined builds have been sitting around for. If you want to get a picture of what the service is doing just look at the event log on the system it is running on.

What’s next?

You tell me! If you have any features that you would like to have added to the Build Cleanup Service then to let me know. I’ve got a few that I would like to see:

• A Windows Installer-based setup package which includes prompts for setting up things like expiry time spans, processing intervals and the Team Foundation Server URL.
• Warning e-mails for those that iniated builds that are going to be deleted.
• Support for changing the build quality indicator to “Deleted”.
• More robust error handling and logging.