Imagine you have a friend who writes a blog. Maybe you actually do. Let’s call him ‘Chump’. One day you’re chatting, and the conversation turns to technology. It turns out that Chump is using Dreamweaver to write his blog entries, and manually uploading them to his site via FTP. You’re appalled.
How do you update the RSS feed?
you enquire, trying to conceal the horror in your voice.
Oh, I just edit the Atom file manually, it’s not that hard.
says Chump.
Maybe nobody ever told Chump about wordpress.
At work, we just switched our build server from CruiseControl.rb to Hudson, and we won’t be looking back.
Ruby people, for some reason, seem distinctly inclined to use build servers made out of Ruby too. That’s nice and everything, but these things are childsplay in comparison to the maturity, usability, and feature-set of hudson.
Here’s why I recommend you switch to hudson for your Ruby / Git projects:
- open source
- piss easy to set up, even if you have no idea what java even is
- solid git support
- works with CCMenu (or your favourite CruiseControl monitoring desktop widget)
- kill builds from the GUI
- in fact, manage everything from the GUI
- distributed architecture, allowing you to delegate builds to multiple machines
- huge, active plug-in support
- you have better things to do with your time than faff around hacking on your build server
The problem is, it doesn’t have a smug website with fancy branding, so you probably overlooked it the first time. Go back and take another look.
I’ve no experience with Hudson so cannot comment on that but I meant to mention this to you the other day Matt, TeamCity now supports Git too. Having seen developers here become Continuous Integration converts almost instantly when considering TeamCity versus CruiseControl.net it’s certainly worth consideration too. Perhaps a little late for you but I thought worthy of note for anyone reading this post.
Hope all is well, Dan.
Have to give another +1 to teamcity. Especially now since it properly supports Git out of the box.
We did the same here at imedo and we really like hudson. We had some problems with the svn plugin (although I think it was a problem with the svn server in the end) – we use git now anyway.
Hudson is really great for distributed builds. We use two slaves at the moment but it’s really easy just to add another ten or so slaves to speed up the overall test runs.
+2 to Hudson.
@Dan, @Ben
Judging by TeamCity’s licencing, it could get pretty expensive if you wanted to run a decent sized build cluster / cloud / grid. Plus, does it have a continuous integration game? I think not.
+1 to Hudson. 🙂 We tried it out after I saw your tweet about Hudson, and we haven’t looked back. It is soooo nice. It just works and is very slick. TeamCity does look interesting, especially since you can easily parallelize a single build job but we are pretty happy with Hudson for now. BTW, have you managed to parallelize your specs and Cucumber features with Hudson?
@mabes
Yes we have! Nothing to do with hudson, actually, but Dan has done some amazing work to get testjour working on our ubuntu build environment, and it is just incredible. We’re running 6482 steps (on four ubuntu VM slaves) in just over 15 minutes!
Ahh, that is very cool. My question though, was if you are running your specs the same time as your features or if you run them serially. I guess I just need to make testjour work with RSpec.. because ATM that is the bottleneck for my current project.
OK I see what you mean. We currently have a single build task that runs them serially (features then specs), but I think we’ll definintely experiment with running them in parallel soon – I’d like feedback from both ASAP.
@Matt @Ben, Have you tried deep-test? http://github.com/qxjit/deep-test/tree/master
Hi JM.
I’ve not tried DeepTest yet, no, but we’re using testjour (http://github.com/brynary/testjour/tree/master) for distrubuting Cucumber tests and it’s great.
We”ve used CC, Luntbuild and hudson.
Hudson is by far the best application of all 3. Dead easy to setup, stable, great UI and lots of plugins which are also easy to setup.
Using is for Java(ant + maven) and Ruby.
I love Hudson. After futzing with the Java version of CruiseControl a few years back, I tried Hudson and I was blown away by how I could configure EVERYTHING in the UI. And it’s just gotten better over the years. Now you can even install plugins from the web interface.
I definitely recommend Ruby folks give it a shot. It has a rake plugin, or you can just have it run a shell command.
Latest Software Test and Performance Magazine article referenced Hudson as their CI builder, so I thought I’d try it. We didn’t have any Java running on our Ubuntu build server (it was installed, but nothing was using it), but Hudson put a big hurt on the server, slowing it down noticeably. We didn’t see any advantage over CC.rb, and since the server was also our project’s database and source control (svn) server, we uninstalled it and went back to CC.rb.
CC.rb 1.4.0 (http://github.com/thoughtworks/cruisecontrol.rb/tree/v1.4.0) is now available and supports git, hg and bzr. We plan to support building on JRuby and Ruby 1.9 fairly soon.
Yeah, the best reason I see not to use Hudson is to avoid having a heavy Java server (even jetty) running.
If you have a LAMP (or Rails) hosted or VPS build server, then you might be hesitant to take the memory and CPU hit. I’m working on a way to make it easier to get a dedicated build farm running.
Wouldn’t it be nice to have an account somewhere that could run CI and even parallelize build and testing out? I want to work on something like that
Agreed Aaron – I just recently needed a build server to run on the Dreamhost shared host this blog runs on, and the Dreamhost admins kept killing hudson because it hogged too much RAM! Integrity fitted the bill nicely in the end (though getting a sinatra app running on Dreamhost was a world of pain).
You’re right it should be easier to delegate builds to a 3rd party. http://runcoderun.com/ are having a good crack at it.
I just switched from CC.rb to Integrity, but am interesting in Hudson as Integrity works, but leaves some things to be desired. My main question is how much memory do you think you need on an Ubuntu box to run Hudson for a single Rails project? I’ve been running my CI server on a 256MB slice at Slicehost, in part to keep costs down. From my past experience with Java, as folks indicate above, it seems I’d need a lot more memory to get Hudson working. I can probably go up one level, but I’d rather not jump up to a 1GB machine and incur that cost when I have a fairly decently working setup.
I am also in the middle of setting up Testjour, and that’s how I came across this blog entry, as I’m having some issues simply starting up slaves. Do you have the correct command line vs. what’s documented? i.e. I’ve found I need to use “testjour run:slave”, instead of the “start:slave” in the README, but it seems to want a URL as well?
Hey Chris,
We run Hudson on in-house hardware, so we have the luxury of being able to add RAM fairly cheaply. Here’s the output from ps on our build server:
So it looks like we need about 1.5GB to run our Hudson. YMMV.
For running testjour slaves, we use this in our rake task:
def runfeaturegroup(feature_group) slaves = [] slaves << "--on=http://hudson@of1-dev-buildslave1.srv.songkick.net:15434/var/lib/hudson/skweb" slaves << "--on=http://hudson@of1-dev-buildslave2.srv.songkick.net:15434/var/lib/hudson/skweb" slaves << "--on=http://hudson@of1-dev-buildslave3.srv.songkick.net:15434/var/lib/hudson/skweb" slaves << "--on=http://hudson@of1-dev-buildslave4.srv.songkick.net:15434/var/lib/hudson/skweb" # profiles are defined in cucumber.yml # subsystem profile excludes filestore features from the build sh("testjour #{slaves.join(" ")} -p #{featuregroup} --max-local-slaves=0 features/cucumber/#{feature_group}") endI’d advise having a look at the testjour code if you’re not sure what it’s doing – it’s still pretty immature and not especially well documented yet.
Thanks Matt. Do you use the master branch of brynary’s testjour, or have you guys forked it, etc.? I’ve been starting to prowl through the code (which is how I’ve found differences in command line args from what the docs have), but I don’t see an “–on” param for example. I will keep prowling, but lemme know if you have a fork, etc.
I will also probably give Hudson a shot. I’m going to bump my CI slice up to 1GB and see if it runs in that. The incremental cost is ok. Looks like Hudson supports GitHub post-receive hooks via a plugin someone has on GitHub, you guys using that?
We have our own branch at http://github.com/songkick/testjour/tree/master but I don’t think it has anything particularly special in it – you should be able to use Bryan’s branch just fine.
We don’t use github for our main application code – again we just run a git repo in-house, so I’ve never needed to try the hooks. We just get hudson up to poll the repo for changes every minute, which is good enough for us. I’m happy to hear there’s a github plugin though. Want to post back here when you’ve tried it and let us know how it works?
I gave Hudson a go, but couldn’t get it completely working for my build. I have to agree it looks great though. Oh, and it ran (for my project) on a 1GB Slicehost slice just fine. I wound up going back to Integrity due to the problem alluded to. I wrote this all up in case it helps anyone else: http://codeintensity.blogspot.com/2009/08/further-continuous-integration-travels.html
Make sure to use the nabaztag-Plugin !
http://slowtwitch.de/wp/2008/12/hudson-nabaztag-publisher-plugin/
Have Phun
Stephan