Some questions about Bamboo

Romuald Tisserand

Hi,

I work in a small software company (15 developers). We currently run BitBucket and JIRA On Demand (in the cloud) and we don't plan to change this. We also run our own build infrastructure (based on a set of Powershell scripts).

 

What we do is Eclipse RCP applications (features, plugins, all those Eclipse stuff). To build our projects, we need several JDK versions (some projects use 1.5, others 1.7, etc), several Eclipse, and so on for all the dependency chains. That means there are a lot of possible combinations. That's why our build system procedure is something like this:

1. Checkout the source code from BitBucket
2. Get Java version and the dependency chain from some config files
3. Gather each dependency to assemble a whole Eclipse environment
4. Run the PDE build

 

We're thinking of get rid off our build system to adopt Bamboo hosted on our own server. I've just read the Bamboo documentation for few hours, and I've some questions to start straight in the right direction as much as possible.

 

1. Will be able to connect our self hosted Bamboo server to our JIRA On Demand?
2. Regarding our constraits about dependency combinations, how should we think about the agents?

 

We plan to have a configuration to run 2 or 3 concurrent builds. I don't have a clear idea about using local or remote agents except that we plan to run only one build server. I think remote agents can also run localy, am I wrong? As we need to build with several JDK versions, what's the best practices to set up Bamboo.

 

Any help would be greatly appreciated. Thanks.

Steffen Opel [Utoolity]

This are indeed several topics embedded into a single question - I'll try to briefly answer them here, but suggest to create separate questions for a more elaborate discussion, if need be:

Bamboo Server with JIRA Cloud

This works fine as such, i.e. you can link all Atlassian Server and Cloud applications in principle in order to gain the resp. integration features - you might encounter a few limitations or differences here and there still, though I would treat each of them as a bug and file an issue accordingly (for example https://jira.atlassian.com/browse/BAM-15891).

Constraints (agents)

As outlined in Agents and capabilities and further clarified in Difference between Local agents and Remote Agents, a local agent runs as a component within the Bamboo Server's JVM process, whereas a remote agent runs as a separate standalone Java application with its own JVM process.

For production environments I would therefore highly recommend to not use local agents for anything but simple build orchestration scripts (if at all) for separation of concerns, i.e. to ease dependency management and ensure that your server is properly isolated from build load and possible issues within your build pipelines.

• Please note that Bamboo's licensing allows for unlimited local agents, but requires a higher tier depending on how many remote agents you want to have at your disposal (your scenario of 2-3 concurrent builds would ask for a 5 agent license for example).

Other than suggested by the referenced knowledge base article, you can run a remote agent locally alongside the Bamboo Server too in principle, though this is generally not advised either for the aforementioned reasons (one can meanwhile alleviate this to some extent by using Docker based build agents, see below).

Constraints (dependencies)

There are several ways to approach this (and to mention this right away, Bamboo lacks a feature some users coming from Jenkins might be used to, see https://jira.atlassian.com/browse/BAM-5813) - I'm subscribed to striving for Dev/prod parity, and Bamboo has always supported this well by means of its Elastic Agents (remote agents on Amazon EC2), which allows to (possibly automatically) spin up a new agent (aka environment) that is providing the exact dependencies you need by matching agent capabilities with build requirements (and eventually tear it down again after each build to guarantee isolation) .

The elastic agent flexibility comes at a cost of course (notably it requires an AWS account, and ideally a bit of resp. know how), but is meanwhile accompanied by Bamboo's Docker support, which comes in two flavors:

• 1. You can facilitate Docker based build agents and simulate all or parts of the elastic agent concept in any way you see fit, e.g. by running (possibly on demand) those remote agents on the same instance as the Bamboo Server, another instance, several instance types depending on build requirements (e.g. one CPU and one memory bound), or even a dedicated one per agent, just like with Elastic Bamboo.
  2. You can facilitate the Docker task to isolate build steps into a Docker container:
     In this scenario the Bamboo agent starts a new Docker container for each respectively configured build step, which provides perfect isolation, but requires the entire build step to be managed via a build script in turn, as just recommended and outlined by @Ian Buchanan in his insightful answer to What is the Bamboo equivalent of a Jenkins matrix job?
  3. Depending on your requirements and preferences, you can also mix and match 1. and 2. of course, and I would be remiss if I wouldn't mention Utoolity's (commercial) Tasks for AWS add-on, which (amongst other features) expands on Bamboo's built-in Docker support by offering Bamboo tasks to orchestrate a Docker cluster on Amazon's EC2 Container Service (see also Deploying to Amazon ECS for more on this):
     1. you can schedule ECS services, i.e. run and maintain a specified number of instances of a task definition simultaneously - this allows to maintain a Bamboo Docker agent fleet on ECS for example
     2. you can run ECS tasks, i.e. a one-time or periodic batch job that does not make sense to keep running or restart if it finishes - this allows to run build steps as Docker containers on ECS for example (similar to Bamboo's built-in Docker task for other Docker host environments)