We are a Java shop looking for a CI tool to use. Both Hudson and Teamcity seem to be free but Teamcity seems slicker and with more support.
I was wondering why one would still use Hudson and if anyone could provide any argument for/against either?
A:
I had never heard of Teamcity before -- the website looks slicker for sure. I've been quite satisfied with Hudson, but we're not really pushing it to its limits. It is up and running in a couple of minutes just like Teamcity.
The one big plus for Hudson for me is it being open-source. I see Teamcity supports plugins, so you can probably make it do whatever you want but this might be the only issue that you really cannot add-on later.
Simon Groenewolt
2009-09-10 10:41:38
The question is of comparison for those that have experience with both, not "i don't have experience, but..."
Michael
2010-10-29 17:13:16
+27
A:
+1 for Hudson.
Hudson is a very active project, has a wide community of users and an active users mailing list, is really easy to start with, is easy to use, has been used on huge, very huge, projects (JBoss, JAX-WS, etc) and thus has proven records of success, offers very nice advanced features (e.g. build matrix, build clustering, etc), is open source, has a lot of plugins...
And if support is really an important thing, you can get commercial support from Sun. But FWIW, I never faced any blocking problem with Hudson.
Update: As you may know, Kohsuke Kawaguchi (the creator of Hudson) has left Sun/Oracle and started his own company to take Hudson to the next stage. In other words, this is not a threat for Hudson. And if you are looking for support, you can get a certified version of Hudson CI Server as part of a subscription plan (this certified version bundles a high quality release of Hudson with a predefined set of plugins plus some commercial one).
Update: To illustrate the size of their respective user base, here is a comparison of job trends for several CI tools on Indeed (live query):
This is of course not a technical indicator.
Pascal Thivent
2009-09-10 10:46:03
+21
A:
Team City is by far and away the best CI server out there. Its killer feature for me is the tight integration with IDEs (IntelliJ, Eclipse and VisualStudio). It can show you, for example, when a file you're editing in the IDE becomes out of date, who changed it and what they changed. You can commit from the IDE to the CI server, run the comile and tests on the build grid, and then the CI server will commit if the build is successful. You can click on build reports in the CI web app and it will open the appropriate files in the IDE.
There are plugins available (I wrote one: http://team-piazza.googlecode.com), but not many.
Nat
2009-09-10 10:48:20
Remote run / Pre-tested commit are very useful features of TeamCity. In general TC can be more convenient if your builds are not fast, because in TeamCity you get continuous feedback on what happens in your build (how many tests passed, failed, at which stage the build is and so on). Also TC notifications are more sophisticated. You can configure different rules for different types of builds and for a wide range of notifiers (email, Jabber, windows tray).
Pavel Sher
2009-09-10 14:45:31
@Pavel: I don't know TeamCity as well as Hudson so I won't challenge the beginning of your comment. But, regarding the notifications, claiming that TC is more sophisticated is pure FUD in my not so humble opinion. All the mentioned notification channels are available on Hudson (you can even add twitter). Actually, I bet that Hudson has way more plugins than TC (check http://wiki.hudson-ci.org/display/HUDSON/Plugins) and I'm sure TC has more limitations that Hudson.
Pascal Thivent
2009-09-10 15:07:38
I agree about channels (Hudson has a lot of plugins), but do not agree about rules. In TeamCity you can subscribe to builds with your changes, you can choose to be notified when build begins to fail (e.g. when first test begins to fail). You can ask to be notified on first failed build after success sequence + on first success after failures. And these options are available for all notification channels. One of such channels is IDE notifier: when something goes wrong you will get notification right in your IDE. As I remember Hudson notification rules were much simplier.
Pavel Sher
2009-09-10 15:27:40
Thanks for the clarification. However, are these configuration options that useful? Honestly, I've never felt the need for such complexity. PS: are you working for JetBrains? :)
Pascal Thivent
2009-09-10 15:33:23
In my opinion they are useful. I do not think you want to be notified on each and every failing build even if you did not commit changes to this build. Users do not like to be spammed. And yes I am working for Jetbrains and using TeamCity everyday :)
Pavel Sher
2009-09-10 15:41:50
Pavel - not wanting a slinging match here, but by default Hudson will only email you if you contributed to the failing build. You can also subscribe to be told of every failed build if you want. There's also more options in the email-ext plug-in. You don't have to approve of it, but lets not misrepresent it.
Jim T
2009-09-10 20:34:07
A quick google will show you that there are plug-ins to control nabaztag rabbits and other cute devices from Team City. Or you could use the plug-in that *I linked to in my answer*.The benefit of tight IDE integration is much quicker and more focused feedback about the code you are working on as you work with it. You don't have to wait for a notification, switch to tge browser, read the report, switch back to the IDE, and open the appropriate file. The editor pane changes as you work to show how other team members have affected the code.
Nat
2009-09-10 21:50:51
That Hudson Eclipse plug-in does only a tiny fraction of what the IntelliJ Team City does.
Nat
2009-09-14 19:37:25
As far as I see the arguments PRO TeamCity I drawed more and more to Hudson. Simplicity rules!
Mnementh
2010-03-08 12:43:12
+2
A:
I really liked Teamcity but in the environment I am working it, the time it would take to get a Purchase Order for Teamcity through the layers of management would likely have exceeded the time it took to migrate everything over to Hudson.
sal
2009-09-10 14:04:41
@sal it always amazes me how companies can be so concerned over a couple of thousand dollars for their development teams' tools and would rather have them waste 100s of combined hours that they wouldn't have had with the tool.
Chris Marisic
2009-12-15 13:20:09
@Chris What if they start with open source free tool because just to see how something works out and 2 years later realize it still works without any problems? Would you still suggest spending couple of thousand dollars to upgrade to commercial tool that most probably does exactly the same thing?
stefanB
2010-02-16 22:00:05
@stefan If you've used a tool for 2 years and it meets your needs unless there is featureX that you need from another tool why would you switch to any other tool free or paid for?
Chris Marisic
2010-02-18 15:25:38
+3
A:
TeamCity is great because it allows each developer to have their own build profile and hook into it from their IDE. That a lone is 'butt-kickin'. There is also support for GIT etc. Seriously take a look at it. The professional version is free.
Beaumont Muni
2009-10-18 15:25:26
A:
I'm just starting to get used to hudson ready to experiment and see how it will fit into our current environment. I have absolutely zero experience with Teamcity so can't comment on that but I am enjoying working with hudson thus far.
There are lots of plugins for hudson plus the hudson site gives you plenty of advice for writing your own (http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson).
Jake Worrell
2009-11-11 21:45:09
+2
A:
We started out with Hudson for a couple of Flex projects, then we migrated to TeamCity, when the .NET developers joined our CI efforts. Now we have replaced the TeamCity server again, back to Hudson. The main reasons are: - The vibrant Hudson community, better than support. - The huge amount of plugins for every kind of tasks. - The open source. - Hudson is for free, TeamCity is only free for 10 projects.
subotnik
2009-12-15 13:03:30
A:
The biggest argument against Hudson is that every release introduces new bugs.
Releases are very frequent, so you have to upgrade frequently so you don't fall behind. That means that you need to devote a lot of time to diagnosing issues and rolling back to previous Hudson releases. (Sometimes a rollback isn't even possible!)
We are introducing Continuous Deployment in our shop (when you check in code, it gets deployed on the live site!) and having to wrestle with Hudson is costing us too much.
We are actively looking at migrating to TeamCity purely because of the cost of Hudson's bugs.
jdtangney
2010-08-12 19:57:35
Just because there's an update available doesn't mean you must upgrade. I'd rather they released more- than less-often. It's my choice when to upgrade, and I certainly don't do it every week.Also, the maintainers are very conservative about backwards compatibility. Plugins don't generally require the latest Hudson in order to work. In fact, 130 plugins available now are built against Hudson versions that are over a year old.If you're still concerned, there's an automated rollback plugin in the works.. ;)
Christopher
2010-08-12 21:01:54
From my experience, the problem is more with plugins than Hudson itself, although this doesn't make a huge difference from a user point of view. But, *nothing* forces you to upgrade unless you're facing a particular bug or can't live without a new feature. We simply don't follow each release and not using the ultimate version isn't an issue at all for us: *"If it ain't broke, don't fix it"*.
Pascal Thivent
2010-08-12 21:06:53
When the principal committer sends a message saying that a major security flaw has been fixed, that's reason to update.My point still stands: Hudson is just way too flakey – even with NO additional plugins installed.
jdtangney
2010-08-19 04:51:58
A:
I've been recommending to clients that they consider Bamboo. The reason being that (ok, from reading the spec sheets!) it has a very similar feature set to TeamCity. However the main benefit is very tight integration with JIRA which is quite popular as a feature/bug tracking system. The complete suite being JIRA, Greenhopper, Bamboo and Eclipse. Quite a few clients also have HP Quality centre and there are plugins which joins that to JIRA as well. I also like the fact that JIRA, Bamboo and GreenHopper all come from Atlassian.
Derek Clarkson
2010-09-01 05:45:18