During initial discussions on structuring a new TFS installation, there is a regular but surprising (to me) question why a dedicated machine should be configured to host builds.
I shall explain why the build function should be separated from TFS.
TFS would need to perceived as a production machine on par with Exchange or SharePoint server etc. Any downtime on that server would negatively affect production for the team. The build server however is less restrictive. In general, due to installations and builds, it does need to be rebooted as and when needed. Such as installation of new software components.
This point ties in with the above, but bears mention on its own. To compile and deploy applications, you would need to install several additional components that is not relevant to TFS. This possibly will include Visual Studio 2010/2/3, BizTalk build components, Silverlight, InstallShield build, etc. As you don’t want to affect stability of the TFS server, you separate out these onto a separate server.
The act of compiling is intensive on the CPU and disk access (memory is not that much affected). This will affect calls to the TFS and possibly lead to time-outs.
Surprisingly, I had a client switch off unit testing during build as it was affecting TFS performance (TFS and the Build controller/agent were sharing a machine)
Security requirements differ from TFS application/data tier to build server (http://msdn.microsoft.com/en-us/library/bb668945.aspx#_How_to_Secure)
With TFS server, you never give access to any users. Only the network or system administrator would need access to perform maintenance tasks. However, the build server is less restrictive as build engineer, team leads or even senior developers will have access to perform certain tasks such as maintenance, installation or updates.
This might not be relevant at the beginning, but I have noticed it with teams over a period of time. As mentioned in the second point where you need to install additional software on the server. Although you try to limit this as much as possible, eventually you could end up with conflicting software as the project advances. For example, version 1 is released for a certain release of a software component. For version 2, you need an update to that software component but it cannot be installed side-by-side on the same machine. The only recourse is to move compilation of version 2 to a separate build machine. This separation would then protect the TFS server.
In addition, as the project grows you might end up creating another project collection. Since there is a 1-to-many relationship between build controllers and TFS server, a separate build server would need to be created to service the new collection.