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:
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.
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.
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:
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).
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.
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).
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:
Thanks you so much Steffen for this really detailed answer.
Our issue mainly discussed about dependencies is not a problem between development vs. production, but because of the diversity of our customers environments. So, for us, being able to build on Java 5, 6, 7, 8 with Eclipse 3.6, 3.8, etc plus the dependencies of each projects is a must.
Thank you again, that's really helpful. Now a lot of pointers to be read to improve my Bamboo understanding.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
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...
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!
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