thoughtworks go vs atlassian bamboo [closed]

开发者_Go百科 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Does anyone have any comments on one vs the other.

We're looking at trying to automate our release process from dev into test into uat into production, including running unit tests, having code reviews and enforcing permissions on who is allowed to push builds from UAT into production.

---

DISCLAIMER: I am the Product Manager of Bamboo

@Bernard: could you provide some more details around your process?

• Are the UAT tests manual tests?
• What does pushing into production mean in your case?
• Do you expect a single build result at the end of your deployment?

Bamboo 2.7 is our first release that allows you to divide your Build into different Stages and execute Jobs within Stages in parallel. This can significantly improve the overall turnaround time of your Builds. We are currently working on artifact passing, which will allow you to pass build artifacts between different stages. Again, this will reduce the overall build time and is another important step towards a Continuous Deployment process.

Unfortunately we currently do not have a good "out of the box" way to enforce permissions on certain parts of the build. Again, there are ways to work around this with plugins and by setting up your Build in a certain way. But it's hard to provide suggestions without knowing your process in more details. If you are willing to share the details of your process with us, I would love to speak to you in person (jens at atlassian dot com).

@jgritty: The problems you are pointing out are partially know issues with our Perforce integration and partially seem to be unknown bugs. Please feel free to create a support request on support.@atlassian.com or raise a bug report on jira.atlassian.com.

Since Perforce is less commonly used (compared to CVS & SVN) amongst Bamboo users, we generally get less feedback about it and hear less about existing issues. Please raise problems directly with us and we will do our best to fix them in one of our upcoming releases.

Cheers,

Jens Schumacher

---

I've never heard of Go, but I can tell you that Bamboo has some severe quirks. Depending on your source control system, your mileage may vary.

It takes sort of a least common denominator approach to dealing with all the SCMs it hooks to, so for us using perforce, we lose out on some things we should be getting for free.

Here are a couple of the annoying things that still have not been fixed:

Setup a build agent to use a particular client (must already exist, of course, grr). Now suppose the client is rooted at c:\buildarea. You MUST manually create the c:\buildarea folder otherwise the agent will give you some ridiculous error about not being able to extract the files to the client root. Obviously 'p4 sync -c YOURCLIENT' would do that, but Bamboo does something dumber.

Another thing that it can't do is properly build from an existing label. Let's say you have a cross platform build, and you want to build say linux and windows both from the same exact changelist/label, there is no trivial way to do that in Bamboo. You can fire off the builds at the same time and pray. You can have one sync out the files for the other, but there is no way to build using a label.

One last thing that is a little dumb (but not terrible) is the way it sort of assumes everyone uses CVS in the way that it 'tags' builds. When a build contains a large number of changelists, rather than just call it a changelist and number it once, it lists the "version #" for every file in a changelist. Obviously, not a deal breaker, just a little odd for p4 users.

All in all, none of these issues have killed us, and we use it for several hundred builds per day, and have somewhere in the order of 200 build plans active at any given time. I'm sure I could think of other issues, but many things have been addressed.

---

@Bernard: I work at ThoughtWorks and have much more experience using Go (Cruise) than Bamboo, so I'll just give you info on now Go addresses your query

1. "We're looking at trying to automate our release process from dev into test into uat into production": Modeling and automating your entire release process by way of deployment pipelines has been conceptualized by Go and has been around since its earlier versions( previously called Cruise). Deployment pipelines break a complex build into a series of stages that itself are a collection of jobs. The stages can be manually or automatically triggered. It's also pretty easy to view and control the flow of changes as they propagate through the environments from the pipeline dashboard UI itself. Here is a detailed example of automatically deploying to UAT (http://www.thoughtworks-studios.com/go/2.0/help/rm_deploy_to_environment.html).
2. "including running unit tests, having code reviews": Go enables you to split test suites and run them in parallel. You also get a comprehensive report with detailed trails of which jobs have failed, the tests that have failed, which check-in broke the tests, etc, and email alerts for the build events you choose. Go also auto-publishes artifacts and these can be viewed from the report itself. This is pretty useful when sniffing out a build. In Go, it's very simple to implement ratcheting (http://skizz.biz/blog/2008/03/11/fixing-broken-windows-with-ratcheting/), so you can fail builds that don't meet your coding standards thresholds.
3. "and enforcing permissions on who is allowed to push builds from UAT into production": You can control access to projects and environments with both view and operate permissions by grouping pipelines. Additionally you can lock down who is allowed to trigger a build.

Unlike a lot of tools in the market, Go provides visibility into relationships between triggered builds, environment modeling, aggregating results from parallel builds, ease of auto-publishing artifacts, and auto-updating build agents

@jgritty: Go is the successor to Cruise from ThoughtWorks Studios.

---

I have used Bamboo/TeamCity/Jenkins/etc and reviewed ThoughWorks Go recently against standard CI servers.

I was really interested in seeing if they had cracked the team management and release problem. I personally like TeamCity best but gave Go a shot. I was a little disappointed to be honest, as a pure build server it is no where as advanced as TeamCity/Bamboo. It lacked support for key SCMs and build tools. Also most build server have a lot of support for 3rd Party tools such as FindBugs/PMD/Emma/Clover/etc, Go does not

The one area that is different from other products on the market is the the concept of environments and the ability to move through the different environments. However it was a very primitive version of the concept.

The guys at Thoughtworks are some of the best in the world and have a wealth of experience on development teams and I expect to see more releases of the tool where they really start to address some key problems around software development process

My quick review can be found here

http://diarmuidmoloney.wordpress.com/2011/11/24/thoughtworks-go/