ramboo

I did not want to hijack the thread where I read the reference to this product and have seen it mentioned once before. So I thought I would a new topic on it.

I would be curious as to what some of the bigger issues you had with that product. I ask because once I present TC to my team, other team members will evaluate other product.

Any comment would be appreciated.

Thanks

6 comments

I don't want to say anything negative about Atlassian in general, because I swear by JIRA as the best pure issue tracking system available, but Bamboo was a disappointment. We used it for almost a year and while it did do the basic job, it was never a pleasure to work with. One minor complaint we had was with the UI. While much better than some open source alternatives, the it wasn't terribly intuitive. The most serious complaints, however, were with resource usage. It was a memory and disk space hog. It would slowly eat up more and more memory over time. Yes, it would eventually stabilize, but at way too high a level for what it did as an application. The disk space problem was with build results. As far as I know, there was no automatic way to clear out results and over a months time they would build up to occupy several gigs worth of space eventually filling up the drive causing all apps on that server to fail.

Overall TeamCity feels much more polished and the feature also set favors TeamCity by a large margin. That said, we are now having pretty frustrating issue (http://intellij.net/forums/thread.jspa?threadID=272924&tstart=0) with TeamCity so I don't know that I'm ready to issue a personal verdict just yet, but after years of dealing with Jetbrains as an Idea users, I'm pretty confident I'll eventually get this current problem worked out.

0

In general I'm a big fan of atlass. too, so bamboo was the first choice when we thought of migrating from CruiseControl to a commercial version, which had good build statistics and promised to provide an automatic artifacts cleanup.

We started evaluating bamboo in november or so - we discovered two things with bamboo that annoyed us most
1) memory consumption on the server. In version 1.x they have a memory leak, which forced us to restart every 3 days (this only turned up with big build-logs >50mb).
2) their web-application was horribly slow when watching a build (maybe also due to our bigger build-logs) - but that shouldn't have slown down overview pages.

At that time we were missing agents in bamboo too, but they promised to have bamboo 2.0 out by the end of the year (which had fixed some other caveats), so we waited patiently. Bamboo 2.0 is still in beta now, from the release notes, their memory problems got fixed. Whether their web-app got faster, I don't know.

JetBrains had luck to come at the right time, with a better solution - and a license model which was not as complicated as before.

While bamboo 2.0 seems to get a good competitor to TC, the following TC features are still unbeaten by other products (like bamboo) we evaluated:
- automatic distribution of our own files to agents - TC allows us to automatically deploy new jre (and other stuff) to agents which reduces agent maintenance a lot.
- IDE integration - developers just love it
- 'Notify if build is failing'-option: though we had to fix our buildfiles for this to work properly (we got false positives - anyway in TC3.1 there seem to be better tuning options). We have builds >1h - now sometimes after 30min we already get informed of failing tests, which get fixed even before the failing build has finished.
Some times ago we thought of 'staging' builds - running all fast tests, then a second build running all slow tests. Such thoughts aren't needed anymore with this feature.
- Better email content - bamboo 1.0 just sent 'there is a problem, please look it up in the webapp'-style mails. Very annoying ! TC has quite better content (though we still miss HTML-emails from CruiseContol, which were better arranged than just ASCII content).
- Zipping Artifacts (JUnit/Checkstyle/Coverage Reports and alike) on the server (saving a lot of memory), but nevertheless being able to very easily integrate them in the web-app. Developers just browse them as usual - don't even realize that they see content from a zip.
- Integrating own statistics. In bamboo you had to write a special plugin (or be lucky if there was one) - with TC you just have to read the docs and provide a xml with the needed values. This is easily done with XSLT for us. A pro of bamboo is, that they can generate statistical comparisons between projects, I'm sure TC will have that too soon :D ... in the meantime I'm more than pleased with the new agent statistics.

What me miss(ed) most in TC ? Better LDAP integration Every user has to register and configure its own account before he gets mails.
Anyway we wrote our own plugin for that, just took a day (ok - maybe two ;) ). Now users are added automatically if they commit and are not present in TC.
Bamboo had a MUCH better LDAP-integration out of the box.

We also had to write our own plugin, to get a 'first success after failure'-mail - anyway that seems to solved in TC 3.1 too.

All in all: it was our developers, that voted for TC in the end. We had two teams using bamboo and TC a month each. There was no vote for bamboo in the end.
All other teams that were migrated in the last month didn't complain (yet) - and THAT means a lot :)

0

Thanks Guys,

The topics that are coming up here regarding Bamboo is JIRA and code coverage Integration.

I am curious about how these compare between TC and Bamboo.


Jeff

0

We don't have JIRA, but in TC you can link your commit-comments anywhere you want: http://www.jetbrains.net/confluence/display/TCD3/MappingExternalLinksinComments
Don't know what more integration one would need or what bamboo offers there.

For Code Coverage we use Attlassian (formerly Cenqua) Clover 2. In both build-servers we had to modify our buildfiles to create the reports and upload them as artifacts.
In TC you then can integrate this report seamlessly into each build-result-page (see http://www.jetbrains.net/confluence/display/TCD3/IncludingThird-PartyReportsintheBuildResults).
I can't remember that there was such a feature in Bamboo. (reports had to be downloaded as artifacts and than could be browsed as well of course)
Anyway - you could point bamboo to your coverage-results and it would automatically spot the current coverage-value and create statistics from that. There was a third-party 'Coverage Plugin' available also, which created some nicer stats.
Since we use Clover we don't need those. Clover's HTML reports are far better and include nice history reports as well (though it's a bit tricky to synchronize clovers history-db-files over multiple build-agents).

TC seems to integrate Emma, and according to docs you don't even have to tweak your buildfiles. We never tried this feature.
If you don't have clover and need historical statistics you are able to do this with TC as well - (http://www.jetbrains.net/confluence/display/TCD3/BuildScriptInteractionwithTeamCity , last section) ... we did that with data from our Checkstyle Reports.

0

- automatic distribution of our own files to agents -
TC allows us to automatically deploy new jre (and
other stuff) to agents which reduces agent
maintenance a lot.
- Zipping Artifacts (JUnit/Checkstyle/Coverage
Reports and alike) on the server (saving a lot of
memory), but nevertheless being able to very easily
integrate them in the web-app. Developers just browse
them as usual - don't even realize that they see
content from a zip.


I'm sorry that this is a bit unrelated to the original purpose of this thread, but I'm interested in these two comments that you made. I have looked through the documentation a bit and not noticed anything on this. Can you give me some direction on where I can find out more, especially on deploying resources to the agents. I had considered implementing something like this by creating a 'VCS' plug-in which would actually just access files directly off of a network path.

Thanks!
Ray

0

- automatic distribution of our own files to agents -
TC allows us to automatically deploy new jre (and
other stuff) to agents which reduces agent
maintenance a lot.


The technique is actually thought for deploying custom code to your agents, but you can use for distributing any zip you want. The *.zip is unzipped on the agent side
See:
http://www.jetbrains.net/confluence/display/TCD3/AgentSideExtensions (last section).

Maybe Jetbrains should place a hint to this feature at a more prominent place.
See also http://intellij.net/forums/thread.jspa?threadID=272806&tstart=30 to read more about how we configure build-plan to access the distributed files.
Maybe in one of the next versions there is also better (automatic) property pointing to the plugins-directory (Jetbrains: please feel free to take this as a vote for a not yet existing JIRA-issue :D).

- Zipping Artifacts (JUnit/Checkstyle/Coverage
Reports and alike) on the server (saving a lot of
memory), but nevertheless being able to very easily
integrate them in the web-app. Developers just browse
them as usual - don't even realize that they see
content from a zip.

There are zipped by our ant-buildfiles and than uploaded as an artifact to the server.
http://www.jetbrains.net/confluence/display/TCD3/Ant
(the property for configuring build artifacts seems to have moved in TC3 to the 'General Settings'-section)

We then integrate the reports it in the web app as described here:
http://www.jetbrains.net/confluence/display/TCD3/IncludingThird-PartyReportsintheBuildResults

If a report is not present, then the tab is just invisible. So you can define more reports than are present in each individual build. Of course your build plans have to be standardadized in how the artifact-reports will be named.

Message was edited by:
Stefan Hansel

Message was edited by:
Stefan Hansel

0

Please sign in to leave a comment.