Jun 10 2009

Hudson Continuous Integration and Eclipse Update Sites

I was looking for a development build of the IvyDE plug-in for Eclipse tonight and I stumbled across the Apache Hudson server. You have to check this out. Pretty cool, Hudson running over 150 jobs!  Their build farm consist of both Solaris and Ubuntu servers. What I found most interesting was how they used Hudson for creating an Eclipse update site. I subscribe to the Hudson mailing list, summarized here, to follow what is going on with the project. People seem to use Hudson for a variety of different purposes, such as a cross platform testing tool and even as a deployment tool. I have only been able to get people interested in Hudson as a “Cruise Control” replacement…. but at least it is a good start!

This site also demonstrates how multiple projects can be linked together, triggering builds of dependent downstream projects.  I’m not exactly sure how these jobs were assembled, but at a high-level, Ivy and IvyDE each have its own build loop (job). Each job is responsible for creating build artifacts. After a successful build of either job, a third job is triggered which creates/updates and Eclipse update site.  Pretty slick. (As any FYI, the dev plug-in looks better, new presentation and several new new options)

Another small plug for Continuous Integration. We recently set up something kind of cool (trivial, but cool)! As we continue trying to convince the powers that be, to move away from Weblogic towards Tomcat (or even JBoss), we found a really nice little feature. Since Tomcat and JBoss can hot deploy a new version of the WAR file, just by noticing a difference on the file system, combined with the fact that we can spin up a Tomcat instance in about 2 minutes, we actually created an auto deployment mechanism.  Our Weblogic environment seems so cumbersome in comparison…. We could have built the WAR and deployed in in our build loop, but that would have minimally added another 25 minutes to the loop (let’s just say we have an interesting deployment process). With Tomcat, we did a one time deployment to the location of the WAR file inside the Hudson workspace. Now, with each series of check-ins, we build the WAR as normal and Tomcat instantly deploys it, in seconds! If we were a little more sophisticated, we would write some jUnits to bang against it, making sure we did not break anything or create any new dependencies.  Maybe I will throw that in during my next project!!! I know this integration was possible before (with Weblogic), but no way as simple!  Even better Continuous Integration… on my last project I had Ant spin up an embedded Jetty web server, ran my jUnits against the Clover instrumented code, and finally had Ant shut down Jetty…. Pretty slick, from a code coverage collection perspective…

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png