We just raised a $30M Series A: Read our story

Bamboo OverviewUNIXBusinessApplication

Bamboo is the #6 ranked solution in our list of top Build Automation tools. It is most often compared to Harness: Bamboo vs Harness

What is Bamboo?
Bamboo is a continuous integration and delivery tool that ties automated builds, tests and releases together in a single workflow. It works great alongside JIRA and Stash providing a fully traceable deployment pipeline.
Buyer's Guide

Download the Build Automation Buyer's Guide including reviews and more. Updated: October 2021

Bamboo Customers
Neocleus, MuleSoft, Interspire
Bamboo Video

Archived Bamboo Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
ITCS user
Solution Management at a computer software company with 51-200 employees
Vendor
PRO: flexibility when setting up our builds. CON: lacks support for branched builds using multiple source repositories

What is most valuable?

We are very fond of the flexibility it offers in terms of setting up our builds. We have a wide variety of components we need to build which often require custom actions or manipulations using in house technology. Bamboo allows us to set this up quite easily by the flexible configuration features it includes.

Secondly we really like the integration of the build aspect and deploy aspect. One of the recent major releases included this feature to link build and deploy projects together allowing a deployment pipe-line to be setup completely in Bamboo. This makes the status of deployments very visible and also allows for easy follow up and even rollback in case a deployment causes too much havoc.

How has it helped my organization?

Thanks to Bamboo we are able to build changes made by development quite quickly and allow them to deploy to our internal environments when needed (as well as automated during the night). This significantly reduces the effort required to get something into test.

The fact that all builds use a unified setup and infrastructure makes it much easier to control and adapt the ever increasing number of builds.

What needs improvement?

We are lacking proper support for branched builds using multiple source repositories. The current approach is quite clunky (or non-existent) but it seems there is something in the pipe line for the end of the year according to a recent post on the Bamboo Jira.

For how long have I used the solution?

We have been using Bamboo for about 6 years now

What was my experience with deployment of the solution?

Not at all, over all those years we only had a handful of issues and that's probably because we always take each new update directly.

What do I think about the stability of the solution?

No, we never encountered any serious regression. For the few cases we encountered bugs they were fixed in a reasonable time interval.

What do I think about the scalability of the solution?

Scaling out a build system is not always easy, but thanks to the remote agent technology we are able to scale out and add nodes in a transparent way.

How are customer service and technical support?

Customer Service:

We use a 3d party for our license management, which makes it hard to judge this but we never had direct interactions with Atlassian Customer support.

Technical Support:

Pretty good once you get trough the initial levels of the support team, it can take a while before you are able to prove that there's a genuine issue.

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

We came from Jenkins back in the day, I recall our most important reasons to switch where the enterprise readiness of Bamboo and its integration in the Atlassian stack (Jira and others).

How was the initial setup?

Bamboo is very easy to deploy, all it takes is extracting the distribution and a JRE to run it. This also goes for the remote agents which install by running a JAR which already contains the configuration for communicating with its master.

What about the implementation team?

We implemented in house.

What was our ROI?

That would be 100%, the time saved in development is enormous.

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

We started out using only a number of agents and moved to a bigger setup using many remote agents over the years. The cost depends on the agents used and amount of boxes deployed to run them on.

Which other solutions did I evaluate?

Only Jenkins, see previous answer.

What other advice do I have?

Plan before you start, Bamboo is 'only' that which automates. One should have a decent design of how the build needs to work internally and have that (scripts, servers, descriptors ...) in order before attempting to automate on a large scale.

Secondly, don't be afraid to change things to you application or pipeline to help the automation to be more efficient - for example we replaced massive chunks of hard SQL from the build scripts by a webservice to avoid dependencies to JDBC in our builds.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Senior Build & Release Engineer at a non-tech company with 501-1,000 employees
Vendor
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.

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 technical 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: I am a real user, and this review is based on my own experience and opinions.
Find out what your peers are saying about Atlassian, Jenkins, JetBrains and others in Build Automation. Updated: October 2021.
542,721 professionals have used our research since 2012.
ITCS user
Software Development Consultant at a financial services firm with 1,001-5,000 employees
Vendor
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: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Lead Release Engineer at a tech vendor with 51-200 employees
Vendor
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: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Software Configuration Manager at a marketing services firm
Real User
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: I am a real user, and this review is based on my own experience and opinions.
it_user185772
Senior Software Architect with 5,001-10,000 employees
Vendor
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…

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.

Read more here

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Build and Release Engineer at a tech vendor with 201-500 employees
Real User
APIs were helpful for creating customizations but there are limited options with SSH plugins

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: I am a real user, and this review is based on my own experience and opinions.
Product Categories
Build Automation
Buyer's Guide
Download our free Build Automation Report and find out what your peers are saying about Atlassian, Jenkins, JetBrains, and more!