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

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
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,806 views 0 6
Read article

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