Share via

Build Machine Configuration Recommendations for TFS 2010

  • Article

I've fielded a few questions about what type of machine (hardware, operating system, etc.) works best as a TFS 2010 build machine. The answers probably won't surprise you, but they may serve as helpful reminders as you plan your deployment.

Operating System

Generally, I'd recommend a server operating system (Windows Server 2003, 2008 or 2008 R2) for a team environment. Client operating systems can work fine too though you may want to change your processor scheduling options to give preference to background services. If you plan on serving your drop folder directly from your build machine (which will generally reduce the time required to copy the drop) and you expect 10 or more people to access your drops, I'd strongly suggest using a server operating system as client operating systems are typically limited to 10 or fewer simultaneous incoming network connections.

Hardware

Multi-core CPUs have become very common. If your build machine has a multi-core CPU (e.g. Core 2 Duo), you can configure multiple build agents on a single machine. When doing so, here are some tips to maximize performance:

  • Configure each build agent's working directory on a separate physical hard disk and use the fastest hard drives you have. Ideally, you would have one hard drive for the operating system and one hard drive for each build agent running on the machine.
  • Monitor your build machines' memory utilization during builds. If you have plenty of physical memory free, you won't get much benefit from installing additional memory. If you're close to maxing out your physical memory, however, and the operating system is frequently paging data to disk, you'll see significant benefits from installing more RAM.
  • Disable windows search. It's a model citizen in terms of resource utilization, but I'd still disable it since the build machine will spend a lot of time writing files to disk only to overwrite them again in the very near future.
  • Disable any other non-essential background services/processes.

General

  • Configure remote access for your build machines so that your team can access them directly to troubleshoot build breaks.
  • Setup a network share for the working directories on your build machines so that engineers can access them when there's a build break.
  • If you need to synchronize drop folders across remote sites, consider using Windows Live Sync or some similar solution to mirror your drops.
  • If you need to access your drop folders outside your local network, consider setting up an FTP server that serves up your drops.

I hope you find these tips useful. If you have any questions, please don’t hesitate to contact me.

| More

Comments

  • Anonymous
    March 07, 2010
    Jim great post, What about the build controller?  Is it best to keep the various controllers for TFS on the app tier, a dedicated controller machine or just put the controller on one of the build boxes?