Bamboo Best Practice - Using Agents

General overview

We've already had a look at how we can improve Bamboo's efficiency in the Using stages and Sharing artifacts best practice guides, so here we're going to have a look at how we can improve raw build speeds using Bamboo agents.

Let's consider this simple Bamboo scenario:

Imagine a set of plans that we have developed and are queued, awaiting a build agent to become available to execute the build. This is great, and exactly what Continuous Integration is all about, but we notice that certain plans seem to sit and wait consistently longer than others. This has the effect of slowing our progress, and may be felt later down our development streamline. But why is it happening? And what can we do about it?

Let's examine exactly what's going on.

Each build agent offers a set of capabilities, and each plan will have capability requirements that the that the build agent must meet. These could include a range of executables, tasks and JDKs. Build agents are tailored to match specific plan requirements and as a result not all agents can build all plans. Often, only a small subset of agents will meet all of the requirements for a specific plan. Typically, plans that demonstrate consistently long wait times, are the ones that are waiting for a specific combination of capabilities to become available.

The Build Queued Duration report tells us the average time that a plan sits in the queue until build agents become available to execute it. By examining the report, we can identify which builds are too slow, and also if we are sporting wasted capacity on our systems. So how does this help us, and how can we even out our wait times? Adding required capabilities to a greater number of agents helps to improve parallel builds and even out our build loading. We can achieve this in a number of ways.

Best practice approaches

Using remote agents

Why use remote agents?

Adding popular capabilities to more agents is one way to tackle our wait time problem, however we can also take advantage of remote agents to boost our capabilities. By increasing the number of remote agents to the maximum allowed by our license tier, we can add significant amounts of available build capability which will in turn lead to reduced wait times. We could also consider using elastic agents on AWS.

The following graph shows how adding additional remote agents helped the Bamboo team to reduce build wait times for building Bamboo itself:

When build wait times approached 27 minutes in late 2011, adding additional remote agents with well defined capabilities reduced wait times to less than 10 minutes. The same is also true when wait times approached 33 minutes - additional remote agents ultimately reduced wait times back to less than 10 minutes.

Unknown capabilities

Sometimes remote agents have capabilities that are unknown, so Bamboo will not automatically utilize these when it's looking for agents for a build. Luckily, even if Bamboo doesn't know about these capabilities, we can quickly and easily detect them. Simply:

Bamboo admin > Agents > ${AGENT} > Detect Server Capabilities

to identify the capabilities available on a remote agent.

Adding remote agents

Add remote agents using the Agents panel of the Bamboo Admin page:

Bamboo admin > Agents > Install remote agent

Learn more about adding additional remote agents in the remote agent installation guide.

Using local agents

Why use local agents?

If your license doesn't allow the addition of any more remote agents, then adding a small number of local agents can also help. A sound strategy is to add one or two local agents in the first instance, then evaluate the effect they have had on your build wait times.

Remember: too many local agents can start to impact Bamboo’s performance because local agents run inside the same JVM as Bamboo itself. Unless you have 8 cores and 64GB RAM, ~3 local agents is about as many as you can accommodate comfortably. 

Bamboo Server share permissions and accesses rights with with local agents. Keep in mind that by using local agents in your environment, you’re giving other Bamboo users access to potentially sensitive information you might be storing on the server. 

Adding local agents

Add local agents using the Agents panel of the Bamboo Admin page:

Bamboo admin > Agents > Add Local Agent

Learn more about adding additional local agents in the Creating a local agent guide.

Monitoring agents

Build Queued Duration

The Build Queued Duration report shows how long each build is spending in the build queue, and is an important tool for evaluating build wait times. The build queued duration report also allows you to compare build wait time between different plans.

You can access the report by clicking Reports > Reports > Build Queued Duration and selecting the appropriate build plan for analysis.

Build times plugin

Atlassian doesn't provide support for the plugin in any Bamboo version.

The plugin is available only for Bamboo Server in versions 4.0 - 4.4.3.

The Build Times for Bamboo plugin provides a visual representation of the relative build times of each job in a build, as well as which agent each job was built by:

The visualization display can report:

  • A bar graph of relative build and queue times of jobs in a build
  • Which agent each job ran on
  • Each job's status (red or green) 
  • Jobs that didn't run

The Build Times plugin is an official Atlassian Labs production, and is available from the Atlassian Marketplace.

Learn more, and obtain the plugin here.

Agent utilities plugin

The plugin is supported only for Bamboo Server 3.4 - 4.4.8.

The Agent Utilities plugin for Bamboo allows the ability to use Server Notifications to monitor Bamboo Agents. The plugin can be configured to generate notifications when agents: 

  • Go offline 
  • Are disabled/enabled
  • Have capabilities changed

The Build Times plugin is a third party production by, and is available from the Atlassian Marketplace.

Learn more, and obtain the plugin here.

Last modified on Jul 20, 2020

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.