0
votes

I have two agents set up under one controller. Here is my setup:

Controller: MachineA AgentA: MachineA AgentB: MachineB

However, when I queue a build, the build is sequential - one build is built at a time. I'm looking to build on parallel on both agents so we can have two builds building at the same time.

I'm using the "default Template" for build definition, and "Agent Settings" is set as follows: "Use agent where Name=* and Tags is empty; Max Execution Time: 03:00:00; Max Wait Time: 04:00:00" There are no tags on either agents.

Where should I start looking? what other information should I provide?

3
Here's the MsBuild arguments: /p:TeamBuild=True /t:Build /t:Publish /p:SqlPublishProfilePath="MyProfilePath" /p:VisualStudioVersion="12.0"J.L
Its not supported. And TFS can't jude which agent to use if there are two agents unless you added tags for the agent.PatrickLu-MSFT

3 Answers

1
votes

A single queued build will build all of the projects and solutions you tell it to build, sequentially.

Having multiple agents will let you queue multiple simultaneous builds and have those builds run in parallel.

Think of it like this:

You have a Solution X with Project A and Project B. You have a Build Definition Z for Solution X.

If you have multiple build agents and you queue a single build of Z, A and B will be built sequentially. Your second agent will be idle.

If you queue two builds of Z, A and B will be built sequentially, twice, in parallel, across the two agents. Both agents will be used.

MSBuild does have some flags to enable parallelism, but no matter what you do, it won't spread the workload out across multiple agents for a single queued build.

0
votes

If you upgrade to TFS 2015 and use the vNext build system you can do parallel builds, it you have multiple agents and multiple configurations.

Let's say you have a build with 2 configurations set up (anycpu-debug and anycpu-release) and you have 2 agents, the 2 build configurations will run in parallel.

Each agent has to download the source code and parse it separately, so if you are running the 2 agents on a single (multi core) build server the network and the disk subsystem will probably be limiting you. I've just started playing with it (only have a few builds for small projects) and my builds are about 33% shorter running on 2 agents on a single build server.

0
votes

I don't think this answers the question entirely. For instance, we have set up a validation (a.k.a. Gated) build that triggers on changes to a server directory structure. If two colleagues submit a shelve set, then two validation builds (using the same build definition) are scheduled. However, these builds are processed sequentially by one build agent, even though two other agents are idle. To top things: If I disable the active build agent and trigger another validation build then TFS happily picks one of the build agents that was idle before. It seems that TFS prefers to process scheduled builds sequentially to avoid creating copies of (almost) identical workspaces on different build agents. But that pretty much defies the purpose of having multiple build agents.