Bamboo Reviews and Pricing

Senior Build & Release Engineer at a non-tech company with 501-1,000 employees

Aug 20, 2015

The REST API for our deployment project is still very basic, but with Bamboo, we've been able to implement an on-demand, push-button release strategy.

What is most valuable?

The Deployment Project

How has it helped my organization?

Bamboo, along with its integrated deployment and release pipeline, enabled us to go from a monolithic, once a month release cycle, with many post-release incidents to an on-demand, push-button release strategy where we deployed over 200 times a month with very few to no release-related incidents.

Using this tool, we were able to empower the dev teams to push their own changes to production rather than rely on the operations or release teams to release it.

What needs improvement?

The REST API for our deployment project is still very basic and lacks the ability to provide a decent amount of custom automation. For many things, we had to resort to direct database queries simply because certain data was not exposed via the API.

For how long have I used the solution?

I've used it for five years.

Buyer's Guide

Bamboo

June 2025

Free Report: Bamboo Reviews and More

Learn what your peers think about Bamboo. Get advice and tips from experienced pros sharing their opinions. Updated: June 2025.

DOWNLOAD NOW

855,347 professionals have used our research since 2012.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

Every once in a while deployments would hang and we weren't able to clear them without restarting the service. It didn't happen a lot and it may have been due to how we configured the app on the server.

What do I think about the scalability of the solution?

Not really. As long as your organization is willing to pay a bit more, Bamboo can scale to meet your needs.

How are customer service and support?

Customer Service:

7/10 - sometimes you just want to talk to someone over the phone, but this isn't very easy with Atlassian. They have a ticket support system that's pretty good at connecting you with a customer service rep, but sometimes this means you have to go back and forth, waiting for the representative to reply on the issue in order to isolate a problem.

Technical Support:

7/10 - sometimes you just want to talk to someone over the phone, bu this isn't very easy with Atlassian. They have a ticket support system that's pretty good at connecting you with a customer service rep, but sometimes this means you have to go back and forth, waiting for the representative to reply on the issue in order to isolate a problem.

Which solution did I use previously and why did I switch?

Bamboo was already being used.

How was the initial setup?

It was pretty straightforward. Atlassian standardizes setup across products for the most part, so it was easy for us to install, configure, and navigate.

What about the implementation team?

We implemented it ourselves in-house.

What was our ROI?

We got a ton of product and development time back across the board, which could be translated to several tens of thousands of dollars.

What's my experience with pricing, setup cost, and licensing?

Keep in mind that Bamboo pricing is based on number of remote agents. Agents are what you used to load balance build and deployment tasks, so depending on how large your development shop is, what your software architecture looks like, and how often you intend to build and deploy new versions of software, it can get fairly pricey to support a higher volume pipeline.

Which other solutions did I evaluate?

We evaluated Jenkins and Thoughtworks Go. At the end of the day, Bamboo just integrated better with the other tools we were already using - JIRA, Stash, Confluence - and provided better push button deployment control. Bamboo provided such a seamless delivery pipeline and visibility to all stakeholders through its easy integrations with our already existing toolset.

What other advice do I have?

Make sure you don't become dependent on the tool for basic delivery of software. And this goes for any tool you use for automating the building and deploying of your apps. Meaning, if Bamboo were to go down for whatever reason, you want to make sure you can still build and deploy software. To avoid Bamboo becoming a single point of failure, have all of your script tasks run a file that is managed in a repository instead of writing it in line in Bamboo.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user277122

Software Development Consultant at a financial services firm with 1,001-5,000 employees

Jul 29, 2015

Download

There are some stability issues with Java 6, but it offers build agents for Windows and Linux.

What is most valuable?

Multiple build agents for both Windows and Linux
Automatic branch building - same build plan for trunk and branches
Connections with other Atlassian tools - JIRA and FishEye/Crucible

How has it helped my organization?

We have many developer teams building in Java, especially our Continuous Integration team. Bamboo has proven its value for the teams.

What needs improvement?

There are no areas that need improvement.

For how long have I used the solution?

I've used it for seven years,

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

Once, with Java 6, there were some issues, but thanks to information from Atlassian support we changed to Java 7 and it works fine.

What do I think about the scalability of the solution?

No issues encountered.

How are customer service and technical support?

Customer Service:

I'm satisfied, 8/10.

Technical Support:

I'm satisfied, 8/10.

Which solution did I use previously and why did I switch?

We used CruiseControl, and we switched because of better functionality in Bamboo.

How was the initial setup?

It was straightforward, as the default agent and remote agents install out-of-the-box. Only some memory tuning was needed.

What about the implementation team?

We did it in-house.

What was our ROI?

It's hard to say, the yearly license/support/maintenance costs are low in relation to the added functionality.

What's my experience with pricing, setup cost, and licensing?

I see no problem in paying for support, especially because licensing is remote agent based.

Which other solutions did I evaluate?

CruiseControl
Hudson

What other advice do I have?

It's dependent on how many build teams you have. For small development sites, Hudson or Jenkins will suffice, I think. Because we’re building our main applications in-house, we always choose supported and licensed tools.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

Buyer's Guide

Bamboo

June 2025

Free Report: Bamboo Reviews and More

Learn what your peers think about Bamboo. Get advice and tips from experienced pros sharing their opinions. Updated: June 2025.

DOWNLOAD NOW

855,347 professionals have used our research since 2012.

it_user199380

Lead Release Engineer at a tech vendor with 51-200 employees

Feb 24, 2015

Download

Bamboo easily integrates into an Atlassian stack.

Valuable Features

Ability to interface easily with other Atlassian applications.

Improvements to My Organization

It allows a controlled process in which to build software.

Room for Improvement

Version control for plans is currently not really possible. This is pretty much the deal breaker for me and why I'm moving away from Bamboo.

The Upgrade process is also clumsy and requires manual steps. I'm not a fan of tarballs.

Use of Solution

3 years.

Deployment Issues

You may need to upgrade in steps if you are upgrading a relatively old version.

Stability Issues

At one time we used to have issues with system stability. You may need to tinker with your systems heap settings.

Scalability Issues

You are limited by the number of agents you are willing to buy. This means all your teams end up building on the same agents or worse, the master itself.

This is the second deal breaker for me and why I'm currently advocating to move to a different build system.

Customer Service and Technical Support

Atlassian support is usually pretty good in my experience.

Initial Setup

They need to work on their upgrade paths and deployments. If you fall to a few versions behind you may end up doing a multi-version installation. Not fun.

Pricing, Setup Cost and Licensing

The license is the worst. It costs the most. In addition to that we run it on a very beefy server (HP DL360 G8 with 24G of ram). I would not run this software on subpar hardware.

Other Advice

Pros:

- Integrates well with Atlassian products

- Nice Modern Interface

Cons:

- Agents are limited by the license

- No method to provide version control for Build Plans

- It's expensive

- Most plugins cost $$$

Personally I'm in the process of moving away from Bamboo. Sure it looks nice, but I need flexibility. If you plan on creating a build server for each of your teams or projects, don't use Bamboo and use Jenkins instead. It has a richer plugin base, no limit on agents, and allows version control of plans and configuration easily. It's also open source software so the cost is much lower. Maintaining Bamboo is also a chore, not so with Jenkins which is distributed as a RPM, DEB, and now Docker container. Bamboo I'm still stuck downloading a tarball.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user194892

Software Configuration Manager at a marketing services firm

Feb 16, 2015

Download

The new Salesforce plugin looked interesting despite the fact you had limited control on how the SF package is deployed.

What is most valuable?

The deployment mechanism was neat, and I liked how it allowed you deploy the same release to multiple environments. I also thought the ability to branch build and deployment jobs without needing to use templates or updating job configuration could be useful. Plus the new Salesforce plugin looked interesting despite the fact you had limited control on how the SF package is deployed.

What needs improvement?

Logging, no integration with Octopus
Build time variables did not have ability to select from a list of value
No ability to customize Build version
TFS plugin had no local workspace editing of checked out files, as all files coming from TFS have read-only attribute turned on by design
No history view column adjustment
Password variable values were not concealed within GruntJS logs
Watching build log GUI loses focus at build completion making debugging difficult
Mediocre .Net Code Coverage support and reporting.

For how long have I used the solution?

These observations were part of a multi-department, one month evaluation where we decided to go with a different product in the end.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

No issues encountered.

Which solution did I use previously and why did I switch?

We were using TFS for build automation. TFS proved to administrative to maintain and customize build templates. Plus we were planning to move to Git and found Git's interface within TFS/Visual Studio lacking in comparison to other Git clients.

How was the initial setup?

It was straightforward, although, Bamboo initially creates its main install folder in the home directory of the current user. Even though Bamboo has a 'bamboo.home', Bamboo organizes its different library/build-time/resource component folders separately in the configuration and modifying those proved intensive in comparison to TeamCity and Jenkins where there's is only one 'Home' folder.

What about the implementation team?

In-house.

Which other solutions did I evaluate?

We evaluated TeamCity and Octopus.

What other advice do I have?

While the community may grow over time, please ensure your current/future processes are not hindered by Bamboo's faults. Bamboo is likely to improve with time, it may be advisable to use a different solution until the product grows a bit more mature.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user185772

Senior Software Architect with 5,001-10,000 employees

Jan 26, 2015

Jenkins vs. Bamboo vs. Travis

This is the first article of the Continuous Integration, Delivery and Deployment series. We’ll start out journey with brief explanation of Continuous Delivery. After short exploration of some of the tools used today, we’ll move towards the flow (from setting up brand new environment and getting the code from the repository to the creation of fully tested and verified distribution). Each section will present different approaches, compare different tools and, finally, provide some hand-on examples. After the flow, we’ll explore changes required in the development life cycle. Finally, we’ll dive into last steps required for the transition from Continuous Integration towards Continuous Delivery and Deployment.

“Legacy code is code without tests” – Michael Feathers

According to Martin Fowler:

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

You’re doing continuous delivery when:

Your software is deployable throughout its life-cycle
Your team prioritizes keeping the software deployable over working on new features
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
You can perform push-button deployments of any version of the software to any environment on demand

There is a certain confusion as to what is the difference between Continuous Deployment, Continuous Delivery and Continuous Integration, so let us start with definitions.

Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day.
Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.
Continuous Integration usually refers to integrating, building, and testing code within the development environment. Continuous Delivery builds on this, dealing with the final stages required for production deployment.

Each of the points above depend on those below. In order to do Continuous Deployment, one must be able to continuously integrate and deliver.

In order to successfully and efficiently implement Continuous Delivery, new tools need to be adopted. That adoption should be followed by a change in development procedures and workflow.

Some of the commonly used CI tools are Jenkins, Hudson, Travis and Bamboo. Basic principle behind all of them is the detection of changes in the code repository and triggering a set of jobs or tasks.

Jenkins and Hudson

Both share the same code base and very similar (if not the same) set of features. Both are easy to extend, powerful and free. Their main advantage is in the number of plugins and community support. One can hardly imagine a need that is not already covered by one or more plugins. Jenkins/Hudson can be extended easily. As a downside, such architecture based on plugins comes at a cost of stability. Plugins are of different quality and it is not uncommon for an update to break existing jobs or to provoke unexpected behavior of the system. If one is looking for robust and flexible solution without any cost, Jenkins/Hudson is the best choice.

What is the difference between the two? In 2011, Jenkins forked from Hudson and continued being developed as a OSS (Open Source Project). The decision to fork was made by the creator of Hudson, Kohsuke Kawaguchi. Hudson, continued being under Oracle. In 2012, Oracle formally transferred Hudson to the Eclipse Foundation.

Hudson is oriented more toward enterprise organizations. Additional effort is put to clean the code, stability and performance. On the other hand, Jenkins is more accepted by the community, more vibrant and dynamic. In terms of numbers (commits, new lines of code, plugins…), Jenkins is winning over Hudson.

Jenkins is probably the most popular CI tool. Because of that, finding help and other users is easy.

Bamboo

Bamboo is the product of Atlassian. When compared to Jenkins, Bamboo is sexy. It is easier to use and it looks better. Usability is one of the first differences one would notice. Moreover, it is well-integrated with the rest of Atlassian’s products (JIRA, Confluence, BitBucket, etc).

Major downsides are its price and extensibility. It is the only tool listed in this article that is not free. If one needs to perform some non-common task, it is much more likely that plugin exists only for Jenkins. Same applies to help. Even though Atlassian provides great support, it is not so easy to find other users to talk to or ask for help.

If ease of use or integration with Atlassian products is priority and licensing price is not an obstacle, Bamboo is a great choice.

Travis

Main strength of Travis is that it is simple. Unlike Jenkins that allows almost unlimited plugins, creation of innumerable jobs, complicated flows, etc, Travis is based on a single file .travis.ylm that resides in the root of your code. Even though contents of that file can become complicated, in most cases Travis assumes that we’re following certain standards. Use of standards and simplicity is what often leads to a better and more efficient design.

Travis most of the time knows what should be done without any need to explicitly define the flow. For example, if there is the build.gradle file, Travis will understand that it should be compiled, tested, etc. using Gradle. It inspects your code and acts accordingly. One can switch from Ant to Maven to Gradle without making any changes to Travis or the configuration file.

Travis has a strong dependency with GIT. In cases when some other version controls system is used, Travis is not a good option. If, on the other hand, you are using GIT, working with Travis is like forgetting that CI even exists. Whenever the code is pushed to the repo Travis will detect it and act depending on changes in the code (including .travis.ylm). If there is a problem, you will be notified by email. All CI tools, when setup correctly, should work like that. Kind reminder when there is a problem, oblivion when there is none. Travis, brings this to the next level by, in most cases, removing the need to deal with jobs, configurations and other nuances.

Keeping CI configuration (.travis.ylm) as integral part of the code brings advantages. Through that config, you tell it what to do and he does it.

Simplicity comes at a cost. When complicated, non-standard, nobody-heard-of-it-before type of things are needed, Travis tends to be difficult to fight with.

Tools Summary

All four tools described in this article are worthy candidates as your CI solution. They are by no means all tools one should have in account. There are many others to explore.

My preferences for Jenkins and Travis over Hudson and Bamboo are based more on details than big differences. One cannot say that any of them is clearly better than the other. It is often a matter of personal choice, type of the project or what we’re used to.

For new projects, Travis is my favorite and I use it extensively. It is the new kid on the block (at least when compared with Jenkins, Hudson and Bamboo). It requires a switch in the approach to the CI setup. At the first look, its simplicity can be confusing. However, soon after the initial shock, Travis proved to be valuable, great, easy and fun to use.

Jenkins, on the other hand, fulfills my “corporate” needs that often require I-wish-this-does-not-exist-but-I-have-to-maintain-it type of tasks. It is a beast on its own. While it does require additional setup, maintenance and administration work, that overhead is compensated with almost limitless possibilities.

What is most valuable?

Integration with Atlassian products like Jira,Crowd, and Stash
Easy to setup
Price

How has it helped my organization?

With Bamboo's integration with Jira, we were able to update build status and test reports to Jira bugs/tasks.
In Stash, we were able to improve the pull request review standards by being able to review the build and test reports.
Integration with Artifactory, helped us in auto updated libs and artifacts.
APIs were helpful for creating customizations.

What needs improvement?

Ease of use.
It needs "re-build/Trigger build" switch from Stash Pullrequest.
More 3rd party plugins to support IDEs.
Integration of older plugins with newer version of Bamboo.
More options for deployment plans
Configuring tools to agents (Had to do it manually). It would be nice have sharing from server.
-Docker support
Limited options with SSH plugins, can't use options to it

For how long have I used the solution?

Two to three years.

What was my experience with deployment of the solution?

No issues with deployment.

What do I think about the stability of the solution?

Yes, Regular server/agent being down.

What do I think about the scalability of the solution?

Yes, It needs to allow multiple plans to run on a agent(at same time). Dedicating one whole agent isn't fair, I know we have to buy more agents, but in-terms buying and maintaining more infrastructure isn't scalable either. .

How are customer service and technical support?

Customer Service:

Never used it. Had a decent responses from open forum.

Technical Support:

Never used it.

Which solution did I use previously and why did I switch?

Yes. since we wanted to keep Atlassian suite all-around.

How was the initial setup?

Easy. Just like other Atlassian products.

What was our ROI?

We got the product for a cheap price, so its alright.

What's my experience with pricing, setup cost, and licensing?

We initially got 5 agents for around $2000 excluding infrastructure setup. Now we are using docker containers to maximize the mileage on them.

What other advice do I have?

If you are looking for good integration with Atlassian products and then this is the tool.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.