100

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?

oshai
  • 13,307
  • 24
  • 74
  • 128
pdeva
  • 36,445
  • 42
  • 122
  • 154

9 Answers9

113

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.

Ola Eldøy
  • 5,291
  • 6
  • 43
  • 72
Nat
  • 9,514
  • 3
  • 29
  • 33
  • 9
    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 Sep 10 '09 at 14:45
  • 6
    @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 Sep 10 '09 at 15:07
  • 3
    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 Sep 10 '09 at 15:27
  • 1
    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 Sep 10 '09 at 15:33
  • 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 Sep 10 '09 at 15:41
  • 2
    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 Sep 10 '09 at 20:34
  • 4
    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 Sep 10 '09 at 21:50
  • 2
    That Hudson Eclipse plug-in does only a tiny fraction of what the IntelliJ Team City does. – Nat Sep 14 '09 at 19:37
  • 2
    As far as I see the arguments PRO TeamCity I drawed more and more to Hudson. Simplicity rules! – Mnementh Mar 08 '10 at 12:43
  • This is a very nice argument, but can also be achieved by using for example Gerrit. Gerrit is supported by Jenkins (not TC at the moment) and it allow code review and running that code in your CI *before* committing. – Wernight Feb 21 '12 at 17:25
58

+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):

Hudson build engineer, CruiseControl build engineer, Bamboo build engineer, TeamCity build engineer Job Trends

This is of course not a technical indicator.

Community
  • 1
  • 1
Pascal Thivent
  • 535,937
  • 127
  • 1,027
  • 1,106
  • 88
    Perhaps TeamCity is so easy to use, as not to require anyone specifically employed to configure it? – Henrik Nov 09 '10 at 11:26
  • 3
    @Henrik: Interpretation of the above graph is at your discretion. But yes, maybe TeamCity is magic. – Pascal Thivent Nov 09 '10 at 11:32
  • 16
    If you hire a full time build engineer to run your continuous integration, now you've got two problems: 1) Your CI is hard to work with, so your devs will struggle with it and the knowledge will sit in this one person's head, 2) You're paying someone to do a job that shouldn't need doing! – Niall Connaughton Mar 02 '12 at 16:50
  • 15
    If I was selecting a CI server, I'd pick the one that had the LEAST job openings for a dedicated engineer to administer it it. It's a developer tool and the developers should be able to manage it themselves. If they can't, you either need a different tool or different developers. – Nat Sep 07 '12 at 21:43
  • The job trends graph doesn't imply +1 for hudson at all ... – Sharique Abdullah Aug 12 '14 at 08:09
  • Since 2013 Jenkins has the lead in this graph. It increased steadily. With 2016 the score for Jenkins is about 6x times that of the 2nd placed. On topic: switched from Jenkins to Teamcity (hobby project) – sevenforce Feb 25 '16 at 08:43
17

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.

edit: TeamCity is now free for 20 projects.

Niall Connaughton
  • 14,009
  • 10
  • 50
  • 46
subotnik
  • 244
  • 2
  • 3
  • 2
    The 10 project restrictions has fallen, the only limit now is 20 build configurations. For small to medium size projects maybe enough. – ashwoods Jun 17 '11 at 15:07
  • 4
    Out of curiosity, what features that were available through Jenkins plugins were missing in the TeamCity world? – βξhrαng Mar 07 '13 at 23:11
14

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
  • 141
  • 2
14

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
  • 343
  • 2
  • 4
  • 11
  • 8
    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 Orr Aug 12 '10 at 21:01
  • 1
    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 Aug 12 '10 at 21:06
  • 2
    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 Aug 19 '10 at 04:51
  • 1
    I can say that after a year and a half of using Hudson/Jenkins on one project, while it is a great tool - we too experienced inconsistent quality between releases - and we only upgraded when we absolutely needed to. We found work arounds, including frequent backing up of configuration. I am looking forward to trying TeamCity on my latest project. – JaysonRaymond Nov 07 '11 at 21:55
  • There is a [stable Long Term Support (LTS)](http://jenkins-ci.org/content/jenkins-long-term-support-release) branch of Jenkins (see the tabs) for people wishing more stable, less updates. – Wernight Feb 21 '12 at 17:15
  • 4
    Why should updates and stability be opposing factors? Doesn't that just point to a lack of quality? – Niall Connaughton Mar 02 '12 at 16:52
6

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
  • 22,528
  • 15
  • 64
  • 84
  • 10
    TeamCity professional is free of charge. – Pavel Sher Sep 10 '09 at 14:47
  • 6
    @Pavel, we have more than 20 users and many more builds than that. – sal Sep 10 '09 at 15:02
  • 22
    @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 Dec 15 '09 at 13:20
  • 5
    @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 Feb 16 '10 at 22:00
  • 1
    @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 Feb 18 '10 at 15:25
  • @ChrisMarisic why not using Jenkins? It has all the features that TeamCity has and it is free. Also you can do as many jobs as you have.. I prefer Jenkins.. Also there are a lot of nice graphs where you can see the results and not only in text. – Danny Gloudemans Apr 20 '12 at 09:27
  • @sal, likely because many companies today are still driven by bean counters and MBAs. The rewords for these leaders are profit driven, even if that means sacrificing long-term profits. Their tenure is usually short enough to avoid the eventual fallout, or can easily assign blame to other market factors. – cmcginty Jul 02 '13 at 20:51
2

I have used and setup TeamCity and Jenkins (aka the new Hudson) before and while I would agree that TeamCity is a lot slicker to set up it is only free for teams of 10 users or less. Both systems are very easy to set up and have a plugin system that is well supported. The killer feature in TeamCity is the pre-checkin workflow where you can test code before checking it into source control and the nicety of Jenkins is that it is completely free even if you grow beyond the 10 users and build agents.

runxc1 Bret Ferrier
  • 7,508
  • 14
  • 57
  • 99
1

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
  • 125
  • 6
1

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.

drekka
  • 18,723
  • 12
  • 67
  • 112
  • After extensive use of TeamCity, Jenkins looks very bare-metal. Yes plugins allow you to do anything, once you install them. TeamCity has a mature feature set that gets you going out-of-the box. Yet at the continuous delivery level both leave a proper staging pipeline unimplemented. QuickBuild is an even more feature-rich product that deserves attention, it is payware. – bbaassssiiee Jan 21 '14 at 06:14
  • Having now seen Bamboo in action on a client site, I'm no longer very keen on it. There are some areas around scripting and transferring information between builds that it struggles to do. The results tends to be developers putting all sorts of stuff in the CI's global variable area that simply should not be there. – drekka Jan 22 '14 at 06:45