I think my biggest issue with TFS2010 is the problem that a build controller is tied to a single Team Project Collection (TPC). For a company like mine where we run a TPC for each client this means we have had to start to generate a good number of virtualised build controller/agents. It is especially irritating as I know that the volume of builds on any given controller is low.
A while ago Jim Lamb blogged about how you could define multiple build services on a single box, but the post was full caveats on how it was not supported/recommended etc. Well since this post there has been some discussion on this technique and I think the general feeling is, yes it is not supported, but there is no reason it will not function perfectly well as long as you consider some basic limitations:
- The two build controllers don’t know about each other, so you can easily have two build running at the same time, this will have an unpredictable effect on performance.
- You have to make sure that the two instances don’t share any workspace disk locations, else they will potentially start overwriting each other
- Remember building code is usually IO locked not CPU locked, so when creating your build system think a lot about the disk, throwing memory and CPU will have little effect. The fact we run our build services on VMs and these us a SAN should mitigate much of this potential issue.
- The default when you install a controller/agent on a box is for one agent to be created for each core on the box. This rule is still a good idea, but if you are installing two controller/agent sets on a box make sure you don’t define more agents than cores (for me this means on by build VM I have to 2 virtual CPUs as I am running 2 controller/agent pairs)
Jims instructions are straight forward, but I did hit a couple of snags:
- When you enter the command line to create the instance, make sure there a spaces after the equals for the parameters, else you get an error
sc.exe create buildMachine-collection2 binpath= “C:Program FilesMicrosoft Team Foundation Server 2010ToolsTfsBuildServiceHost.exe /NamedInstance:buildMachine-collection2” DisplayName= “Visual Studio Team Foundation Build Service Host (Collection2)”
- I cannot stress enough how important it is give the new instances sensible names, especially as their numbers grow. Jim suggested naming after the TPC they service, for me this is bad move as at any given time were are working for a fairly small number of clients, but the list is changing as projects start and stop. It is therefore easier for me to name a controller for the machine is it hosted on as they will be reassigned between TPC based on need. So I settle on the names in the form ‘build1-collection2’ not a TPC base done. These are easy to associate with the VMs in use when you see them in VS2010
- When I first tried to get this all up and ran the admin console for the command prompt I got the error shown below
After a bit of retyping this went away. I think it was down to stray spaces at end of SET variable, but not 100% sure over this. I would just make sure you strings match if you see this problem.
[Updated 26 Nov 2010] The batch file to start the management console is in the form
set TFSBUILDSERVICEHOST=buildMachine-collection2
“C:Program FilesMicrosoft Team Foundation Server 2010Toolstfsmgmt.exe”Make sure that you run this batch file as administration (right click run as admin) if you don’t the management console picks up the default instance
- Also it is a good Idea to go into the PCs service and make sure your new build service instance is set to auto start, to avoid surprises on a reboot.
- When you configure the new instance make sure you alter the port it runs on (red box below) I am just incrementing it for each new instance e.g. 9191 –> 9192. If you don’t alter this the service will not start as it’s endpoint will already be in use.
- Also remember to set the identity of the build service run as (green box), usually [Domain]TFSBuild, too easy to forget as well as you click through the create dialogs.
Once this is set you can start the service and configure the controller and agent(s) exactly as normal.
You might want to consider how the workspace is mapped to the your multiple controllers, so you use different root directories, but that is your call. Thus far leaving it all as it was when I was using a separate VM for each build is working fine for me.
We shall see how many services I can put onto single VM, but it is certainly something I don’t want to push to hard. However that said if you are like use with a relatively low load on the build system this has to be worth looking at to avoid proliferation of build VMs.