If you have just started making use of the new builds in Visual Studio Online (VSO), or even if you’ve been using them for a while, you might find the new concept of pools and queues a bit confusing – especially if you are used to the relationship between build controllers and agents in Team Foundation Server 2013 (and earlier) and the limitations that come along with them. It is exactly these limitations (e.g. allowing only a single build controller per project collection) that the pools and queues aim to eliminate.
Not only does the new architecture resolve these issues it also greatly expands your options for organizing and utilizing your build agents. To add to that, you can also now run your build agents on non-Windows platforms (e.g. Mac/Linux)!
Pools
A pool is essentially an association of a collection of one or more build agents to one or more queues. Pools are defined at the VSO account level (or the TFS application tier level). You can create as many pools as you like and you can assign pool administrators to each of them. Different people/groups can be assigned to different pools allowing different groups of people to manage your various build assets.
Queues
Queues are defined at the project collection level and are tied directly to a pool. A queue can be tied to at most one pool; However, a pool can be tied to more than one queue assuming the queues are configured on multiple project collections (not currently possible with VSO). As build definitions are created they are associated with a queue. The queue you select for a build definition ultimately limits the set of build agents that can be utilized for the builds generated by that definition.
When you create a new queue you must immediately select the pool that is associated with it. You can also choose to have the queue created and associated with the new pool automatically at the time the pool is created (it’s an option on the new pool dialog).
Agents
The build agents are responsible (obviously :-) for building your systems’ artifacts (based on the build definitions). Although a pool can be associated with many build agents, a build agent is associated with at most a single pool. Demands are used to further constrain the set of build agents that are available for use when a build is initiated.
Let’s See it in Pictures!
Ok, it’s one thing to read the above explanation but it’s an entirely different thing to see it as a picture :-) The diagram below shows the relationship amongst build definitions, queues, pools and build agents.
You can see that a pool (e.g. Pool-2) can be tied to more than one queue. You can also see that a queue can be tied to only a single pool. Looking toward the right half of the diagram you can see that a pool can be tied to one or more agents but an agent can be tied to only one pool.
While this post does not get into the nitty gritty details of the new build architecture (future posts will cover those), I hope it at least helps to clear up any confusion around the relationship amongst the various moving parts that make up Microsoft’s new build technologies.
Comments are closed.