Simplify continuous integration with Hudson

Software pro Mansfield Moser explains why he favors Hudson for continuous integration and more in this interview with TSS staff.

Continuous integration (CI) and build servers Anthill to AnthillPro to Apache Continuum to Atlassian have all been part of software pro Manfred Moser’s software development tool kit.  Right now he's focused on using the Eclipse Foundation’s Hudson continuous integration server.

After using all of these CI servers, why favor Hudson? In this interview, Moser answers that question and explores Hudson’s benefits; how to get started with a Hudson build; choosing scripting tools; using Groovy, Ruby and other languages with Hudson; Hudson and Android; and more.

At his software consulting firm, Simpligility Technologies Inc., Moser has worked on expanding uses of the Hudson CI server. He’s doing a session on “Using Hudson for a lot more than just continuous integration” at the Oct. 2-6 2011JavaOne Conference.

[Editorial note: Manfred Moser is unable to make it to JavaOne for personal reasons, but Tim O'Brien will be presenting the session and covering all planned topics.]

Just to recap, Sun Microsystems started the Hudson CI server project, which passed to Oracle when it acquired Sun. Oracle split Hudson into the Jennings CI project and a separate Hudson CI project,  and moved Hudson over to the Eclipse Foundation in May, 2011.

TSS: Are you seeing any fallout in your community over Oracle’s handling of the Jenkins-Hudson controversy?

Moser: I think it’s all in the past. It was a split, and the two projects are separate entities now. Both have a pretty good future ahead of them, as far as I can tell.

I’m sitting on the Hudson side, but I’m also constantly sitting on the Jenkins IRC log and looking at what they're doing. I think it’s basically a competitive place now. [For years], there have been multiple continuous integration servers, like Anthill and Continuum. Jenkins is out there [with them]. Hudson is going out there now, moving to the Eclipse Foundation and getting a lot of users, new features and stability into the system.

TSS: What do you see happening with Hudson now that it’s an Eclipse project?

Moser:  It is a big change in the Hudson project. It is already a top-level project there. By the end of this year there will be a full release of Hudson that complies with all the Eclipse licensing rules. There are some tremendous enhancements going in all the time and new releases on the roadmap. There’s a lot of new stuff coming.

TSS: What are you looking forward to in Hudson's new features?

Moser: There’s a lot of emphasis on looking at enhanced security integration with enterprise systems like [Microsoft] Active Directory and LDAP [Lightweight Directory Access Protocol] and more. That will be good, because I hear complaints that Hudson doesn’t work that well in practice on bigger installments.

Thinking on the enterprise level, we are looking at enhancements to manage really big build queues and configurations. That’s where you have lots of builds, and you want one build to sort of be inheriting some setup from another build. That should enable making the full configuration easier, because now you have to trade a new one in manually and configure that, and there’s no chaining of inheritance from one build to the next.

TSS: Why did you choose Hudson? What advantages does it have over other CI servers and tool sets you’ve used before?

Moser: It’s super easy to get up and running.  The install is just that simple. The user interface is self-explanatory, and you have enough features.

The barrier to Hudson entry is pretty much zero. You can download it as a free open source project and keep going, so you don’t need to be a customer or establish some sort of customer relationship with some company. It’s even common that people just download Hudson and run it on their local machine; I do that all the time. When I do Android development, I have my Hudson running in the background.

When I’m done with something, I just like check it into my feature branch that I’m working on at the moment in the Git. I have Hudson configured to build off the local Git branch; not even a remote one, just like straight off the local branch. Even before I push anything upstream it will tell me. And I don’t need to wait for a build. I just switch branch, build the next thing, hack around in that. Then at some stage I may get an email or an alert in the UI that says: “Oops you broke it when you did your last check-in.” Then I switch branch and go again. So, even on a local development station for one person, I can go faster than I would without Hudson.

TSS: Are there any gotchas in using Hudson or other continuous integration tools when doing integration in the cloud rather than in a standard in-house data center?

Moser: You have to monitor your traffic intensely. You have to make sure the right ports are accessed and you have your security turned on because most likely a CI server is going to be publicly exposed. So you need to make sure you keep your security setup properly so that nobody can snoop around on your build and see things they shouldn’t see. Always test security with an anonymous user access and set it up the way you want.

Also, when you run in the cloud with those images, you have to keep an eye on your build queue.

TSS: What’s different when using Hudson to build applications written in other JVM languages, like Groovy or JRuby?

Moser: Some have integration for Hudson already, and others you can just look into using their shells to script for writing a little shell script that invokes your tools. Then it's just a question of getting the tool chain onto the build server or onto the cluster, so that each node has the right tooling installed. And there you would probably just use the provisioning system you are used to using already, either the native packaging or whatever.

If you use JRuby, for example, you can get the whole rake and that tool chain onto each build and then just call it from your shell script. Make sure it fails as a script if there are some failures and stuff like that, and then you are ready to roll.

With other languages, like Scala, the Maven-Scala plug-in works really well. The same goes for Groovy. You can also just use Grails, like Groovy/Grails directly with its build script or with Gradle, which also has integration. So in many cases going beyond standard use cases often involves firing up shell scripts or looking what other, lesser known plug-ins are available.

TSS: What Hudson adoption approach would you suggest to someone who’s been using other continuous integration tools?

Moser:  If you have a critical infrastructure running on a different CI server at this stage, I would just start with a side project just to become familiar with Hudson. Then, you’ll see what you need in terms of security. Hudson has a whole bunch of different security providers, so you can set up different access rows and so on.

Depending on the skill level of your team, you can set Hudson up so that only certain people can kick off a build or change configurations and things like that. But if you trust everybody on the team, then you can just leave it pretty much open running on the internal Intranet. Just find a machine you want to host it on, either hardware or even just fire up an EC2 image, that’s OK in terms of the code being exposed.

TSS:  If you had a team of CI-green people, how would you get them up to speed on Hudson continuous integration skills?

Moser:  Before you get to the CI server, have a build that is automated. So, like a normal build, you’re not even worrying about the release process being automated, just the normal build that needs to be beyond. It’s like the "start up Eclipse and press run" sort of thing; but it needs to be a command-line build ideally. Whether you use Cradle or Maven or Ant or whatever, automating is the first step.

Then you want to have proper version control happening. Sometimes instituting something like that can be an upwards progress; but once that’s there it’s fairly easy.

Hudson is pretty much a drop-in install. You can use the native package management systems or just drop the WAR [Web application archive] into your application server. Then you start introducing it slowly, maybe on a new project and not on a big, big mission-critical project. Just get your fingers in there, and see how it goes.

Next, you institute the whole communications around the CI server, like email alerts.

After that, people will see that the stability increases and test coverage goes up. Then it becomes evident that CI is very helpful.

TSS: What scripting tools are good fits for new adopters of Hudson?

Moser: You can integrate Hudson with your version control system, and just fire it up on an easy build and then scale out from that. Ideally, it’s easiest if you use something like a Maven or Ant build, because there’s really good integration for Maven 3 in Hudson. An Ant build can be easily kicked off.

You can also just use shell scripts; but you just have to make sure that in your build, the shell script – bash shell or whatever you’re scripting – runs correctly on the CI server. Luckily, you can test it out easily and just go from there.

Dig Deeper on Java EE development and enterprise Java platforms

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.