Remote agents vs local agents for continous integration and deployment

Question

We're currently looking at moving our .NET code from TFS source control to Git by using Jira and Stash.

We also like to have a good continous integration and deployment server. So for that reason we are also looking at Bamboo.

All the features seem to be fine. The only thing I don't understand is the Agents part. There are two flavours, Local Agents and Remote Agents.

I understand that Local Agents are installed on the same machine as where Bamboo will be installed. And Remote Agents are installed on other machines. But what I don't really understand is the point of it. Why would you not simply install 5 or so agents locally? Why would you want to do that on a remote machine?

Because of that I'm also questioning if a Local Agent can publish my .NET code to any other remote server?

Is that possible with a Local Agent to publish our code to a remote machine? Or is that where Remote Agents must be used for?

Plasmosome

Have you seen this page? confluence.atlassian.com/display/BAMKB/… – Ancona

@Ancona Yes, that only explains that remote agents are installed on another machine other then where the Bamboo server is installed. Not what the exact difference is. IE. can you deploy to other machines with Local Agents etc. All other questions are in my posts. – Plasmosome

Answer 1

As explained in this link, the main difference between local and remote agents is where they run:

• Local agents run on the same machine as the Bamboo server. They even run as part of the same process/JVM.
• Remote agents can pretty much run anywhere. A dedicated server or VM in your network, or even in the cloud. Remote agents communicate with the central Bamboo server using message queues (JMS).

To help decide which one you'll need, try to think about how many agents you're going to have - initially, but also think longer term.

If you're only ever going to have one agent, you can probably do that with a local agent. If you expect to keep growing the number of agents over time, you might want to plan for using remote agents.

A couple of arguments for using remote agents are:

• Flexibility: As you grow, you can easily add more remote agents as required. The elastic cloud deployment can really help if you need to quickly bring up more agents.
• Scalability: If you're only using local agents, they will all run in the same Java Virtual Machine (JVM). Each local agent will consume CPU and memory, which means that you can't scale endlessly. Using remote agents, each agent has its own process, which will allow to scale the agents better without hitting the OS limits with regards to process size/memory usage.
• Location: You can have one central Bamboo server, and then support multiple individual teams with that, e.g. if you're a global company. Each team could run their own build servers with dedicated remote agents, and dedicated configuration.
• Failover: Having multiple remote agents, and having them separate from the central Bamboo server will allow you to restart agents in an easier manner. If everything is run in the central Bamboo process, if you restart that, all of your agents will restart as well.

With regards to your network questions: Sure, you can deploy from a remote agent or a local agent to any other server. You'll need to establish network access between the servers, as long as you have that, you deploy pretty freely. We are using SSH/SCP/SFTP in most cases, but also HTTPS for deploying using web services (e.g. Tomcat or JBoss).

In general, you'll have more freedom and flexibility with remote agents. The downside is the slightly more complex installation/configuration. If you're intending to grow beyond one or two build agents, it's usually worth the effort.

Ancona

Additionally if you solely use local agents you have the potential to slow down your Bamboo instance itself causing it to become unusable while a build is running since the build is taking up all the systems resources. – Mercurous