How can we improve Azure DevOps?

Build Agent Priority

This suggestion is migrated to Developer Community. Please use below link to view the current status.
We currently have 3 on-prem build machines, with 4 build agents each.

The priority to "grab" agents seems always to be in the order that they were installed (in our case we installed server by server), so if a Build uses 4 Agents, they all get used from the same server.

For us, it would be faster if the build agents that get used for a single build would be spread across servers.

So my suggestion is that you have the ability to set "Agent Priority", so that we can have Build Agent 1 from each server as a Priority 1 Agent, Build Agent 2 from each server as Priority 2 etc.

This way, we could evenly distribute the load to these machines.

96 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Michel Zehnder shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Orion Edwards commented  ·   ·  Flag as inappropriate

    The biggest reason we want this is to determine which build machine is the "best".

    We had the following situation:
    - Single big fancy build machine, running for a while, but sometimes it's busy
    - Create a secondary smaller build machine as a backup

    Now ALL THE BUILDS get queued on the backup.
    As a workaround, we removed and re-added the big build machine from the agent pool, but this is a terrible way to manage things.

    Simply putting an integer "priority" field in the build agent config screen would easily solve this

  • AdminVSTS Team (Product group, Microsoft Visual Studio) commented  ·   ·  Flag as inappropriate

    Hi all, this is great feedback, I just wanted to let you know that we have made some improvements to the way we handle agent assignment that should at least help prevent the scenario where all of the builds go to the agents on a single build machine despite having idle build machines with no busy agents.

    For example, if you had 3 machines (A, B, C) and each has a few agents we will assign the builds to the agents by looking for an available agent on the most idle machine.

    I'll leave this item open though since it has plenty of good ideas for giving you more control over the process.


  • commented  ·   ·  Flag as inappropriate

    why is this not a thing? I see hunders of build on first agent and 1 on the 3rd... round robin would be great.

    or the comment by Wagner makes sense.

  • James Pennington commented  ·   ·  Flag as inappropriate

    I'm definitely interested in the priority selection. We have a number of local TFS build agents across multiple computers. Some of these computers have better CPUs / SSDs etc. in them and it would be nice to have the lower end systems be used only if the high end systems are busy. The current process for doing rearranging this is a little painful.

  • Wagner Cordeiro Janissetti commented  ·   ·  Flag as inappropriate

    Add features like:
    - Priority: define priorities for buildings
    - Rotation: after using a build agent put it at the end of the agents list. Use others before this one.
    - Random: define settings for random/not random

  • Erik Medina commented  ·   ·  Flag as inappropriate

    This would be especially important for private build agents hosted in Azure that use the recently introduced B series VMs with burst metering. The current implementation for agent selection in VSTS heavily favors the first agent that's registered which means the banked CPU credits for that agent's VM will be drained faster than the rest of the VMs in the pool resulting in slower builds due to less time being able to burst to a full CPU load.

  • RW commented  ·   ·  Flag as inappropriate

    Seems that TFS will constantly use the same agent it used for the previous build as its next agent, rather than picking an available agent randomly from the pool.
    This is different from TFS2012 for sure.
    If I have 48 agents waiting, it will keep using the same one.
    This makes it more difficult to get to the workspace of a failed build and investigate it because it can be overwritten in that workspace so fast by the next build.
    This is a little frustrating. Also, by not randomizing it, build servers are not exercised properly to expose differences or problems that may arisse.

    Add a setting for this "Random/Not-Random"

Feedback and Knowledge Base