Best architecture for globally distributed teams?

Our company is growing rapidly and we have numerous teams across the globe. We are evaluating the best way to support each team while still keeping costs (multiple licenses) and maintenance/upgrade needs to a minimum. Here are the two options we are looking at...

1. One central Bamboo server with agents at each location to minimze network lag for each local team's builds.

2. A Bamboo instance and assciated set of agents at each location.

Has anyone tackled this situation yet?

1 answer

1 accepted

1 vote
Accepted answer

It depends on a few factors. If you have 1 central SCM repo, you may want to place your Bamboo server/agents near your source code repository as some of the slowest parts of a build are the checkout of code.

Will you be producing large artifacts? If so, once remote agents build an artifact they relay it back to the main Bamboo server. If the 2 are globally distributed, depending on bandwidth this could be slow.

Do you have special data handling requirements (Export Control, HIPPA or other country specific limitations on your data)? If so you may need to have 1 Bamboo installation for your E.C. or HIPPA projects and 1 for others.

Another con to a central server is that the limit of remote agents is 100. If you need more than 100 agents you must deploy another Bamboo server.

Good points. We have one central SCM repo, but we mirror it at each location to minimze read delays for the teams and situations just like this. Some of our builds do produce large atrifacts, so it looks like we may need local Bamboo servers at each location...


I don't think the agents at each location buy you anything. As Adam mentioned, that's potentially a lot of data traffic going from agent -> bamboo_server_home at the conclusion of each build.

Another important bit is user behavior. A dev will have an expectation that when he/she commits code, Bamboo will trigger next to instantenously (if triggering strategy is commit) regardless of where services are physically located. This means that any lag introduced by mirroring, replicas, etc... at the scm level might result in confusion or frustration waiting for a 'sync packet'.

I would try to have all of them located within the same data centre or region. Bamboo server, agents and scm server. Then there's only the lag between a user's desktop and the scm source server.

Accessing Bamboo instances over your web browser should be pretty performing regardless of where your instance is (assuming you're network's dependable). A user's main interface with Bamboo is their scm 'commit' and the webapp. Our devs hardly ever need to go to the agents themselves. As far as they know, they're disposable.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Monday in Confluence

Organizing your space just got easier - Page Tree Drag & Drop is here

Hi Community! I’m Elaine, Confluence Product Manager. You may have read my earlier post about page tree in space navigation sidebar. I'm excited to share another improvement that helps you organize ...

138 views 3 4
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you