Best architecture for globally distributed teams?

[Josh Anderson]

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?

[Adam Myatt · Accepted solution]

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.

[Josh Anderson]

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...

[ReneR]

+1

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.