Hudson vs CruiseControl, presentation from 2008

(Note: Because it's historical, I will still keep the hudson name in that post, but that content of course also applies to Jenkins.)

Looks like Google Docs doesn't allow viewing my Open Office presentations. I digged that old Hudson vs CC presentation I made in 2008. You may find some interesting notes in particular:

• Slide 13: some stats on hudson source


• Slide 14: some stats on hudson releases where I plotted releases from 1.04 to 1.210 (pretty impressive rate at the time !)


• Slides 15&16: Hudson success factors


• Slides 17: Benefits


• Slides 18: 4 things to do:
  
  
  
  1. Try it
  
  
  2. Like it
  
  
  3. Use it
  
  
  4. Contribute
  
  
  
  

Enjoy!

Interesting CI / test distribution strategy

From: the hudson user list

In order to split our build across multiple servers, we have implemented a JUnit "PartitionedSuite" class. When we run our build in maven, we say -Dtest=PartitionedSuite and we pass in an "x/y" parameter like "2/5" or "1/5". The "PartitionedSuite" class scans the classpath for JUnit test classes and puts them in "y" buckets based on the hash of the Test Class name, and then only executes the Tests in bucket number "x". This way, we just define the "x/y" parameter as a per-server variable, and execute the build on y servers, and each server runs one "Partition" of Tests.

Strategies for managing many small maven2 and hudson projects

So you finally decided to structure your maven2 projects properly, e.g. identify the correct set of plugin versions/configurations that work well in your environment, introduce a set of corporate POMs.... You also decided to clean up your hudson usage, use new plugins, etc...

You have to change many POMs, probably adapt hudson projects as well. You don't want to change all those configurations one by one. The good news is that both maven and hudson use XML as storage for the config files.

Here are some tips and tools you might want to use:

[ANNOUNCE] nosyd 0.0.5

Changes since last announced version:

0.0.5 (2009-10-09)
==================

- Nosyd should now run on Mac OS X
- Mac OS X / Growl notifier support (http://growl.info/)
- new Django builder
- new CLI options (--stop)
- be smarter at identifying the monitored project files
- some performance improvements (cache some of the monitored files resolution to lower CPU usage)
- auto-rebuild project when .nosy file is changed

0.0.4 (2009-10-06)
==================

- setuptools support. Project split into multiple files

More info here. Code still on github.

(Thanks to Sergio for testing on Mac OX X)

[ANNOUNCE] nosyd 0.0.3

Some more features since 0.0.1:

• support of maven2/surefire builds and (untested) trial
  
• new command line features: --clean
  
• auto-reload of nosyd and project configurations
  
• configuration for nosyd
  
• try to be more cross platform (untested)
  

CITConf Paris followup

I was supposed to attend CITConf last week-end, but some real-life virus forced me to cancel my trip. The same virus that kept me in bed most of the week. #&#"(¤/"

There have been interesting discussions on the mailing list:

[ANNOUNCE] nosyd 0.0.1

I got tired of having multiple nosy.py windows. So I daemonized the whole thing to run a unique instance per user.

Forget (my version of) nosy, here's nosyd, the _minimalist_ personal command line friendly CI server. It's initialy geared towards building python projects (hence the name).

Lightweight personal continous integration

Getting timely feedback is the key to improved software development productivity and software quality. That's why we have automated testing and CI servers.

Running a full CI server on your machine is a solution I've used in the past for some middle size projects. Using a personnal branch on a distributed SCM is another solution for complex projects / long running branches.

For simple projects, you can easily run a basic CI-like system on your machine. I call this lightweight personal CI.

Jeff Winkler's original nosy script is a great reminder that software should be kept simple and right to the point.

See also Doug Latornell's version

Here's my humble version, with a couple of extra features, in particular Gnome notifications and parsing of the XUnit like XML result.

Too bad I am hitting a lib notify Markup notification issue on Ubuntu 9.04, I can't display pretty HTML. On an unrelated note, launchpad 3.0 launched yesterday.

Tips for autodeploying J2EE apps on Unix platforms

With a little bit of configuration you can have a nice autodeployment setup to save you time and remove potential errors.

For example this is something I can usually do after spending a few hours on the development infrastructure:

# from the build server, deploy the latest build for the specified project onto the 3 dev servers
deploy_build projectName trunk latest dev1 dev2 dev3

# deploy specified build for specified project
deploy_build projectName trunk build65 dev4

# deploy latest branch 2.0 onto specified server
deploy_build projectName 2.0 latest dev5

Also with a little bit more glue code those same commands can be run through your CI server interface, allowing one click deployment from the CI server GUI.

This is one way of achieving it, using standard Unix tools.

Hudson, maven and git on eapps.com VPS

VPS hosting from eapps.com is a reasonable compromise between cost and hosting service quality. I use it to host a hudson CI server.

This entry explains how I set it up up to a point where I can build using maven a java project hosted on a ssh protected git repository (on github). I will not go into the hudson specific stuff, the hudson wiki is usually complete & well worded. But I will spend more time on the OS specific stuff such as daemon configuration, ssh specifics, etc...