First and foremost, you must be using some source control system. Doesn't matter if it's CVS, Subversion, Git, Mercurial, or Bazaar (Hudson supports all these), but you need to have this set up so that Hudson can both consistently check out your software and so that it can notice when to do another build.

Second, you need a test suite. It doesn't have to be perfect, or have 100% test coverage, but you need something that Hudson can run to verify your builds.

Since Hudson sees the world through Java-colored glasses, you'll also need to set some things up to impedance match its idea of how things get done with Perl's. Fortunately, Hudson has the concept of a "free-style" project. A free-style project can use arbitrary shell commands as parts of it build steps, which means that your 'make' and 'make test' can still be used.

Your 'make test', however, will need to be filtered through something that will transform TAP into JUnit XML. Graham TerMarsch's TAP::Formatter::JUnit can do this for you - use the newest version, as it has a lot of fixes and extensions to project Hudson's XML parser from the vagaries of TAP output. (TAP doesn't worry much about character sets, or entities, or any of that other stuff, while Hudson's XML parser falls over at the merest hint of something that isn't straight ASCII or one of the very few entities it understands natively.)

There are options for Hudson to simply point at a file in a subdirectory in the build and display it as part of the build status page. This can be used to show Devel::Cover coverage reports. Both perlcritic and jslint can be persuaded (with a little output filtering) to display data in a format that can be transformed into JUnit as well.

I'm hoping that the talk I submitted to OSCON on this will be accepted, which will give me an excuse to write all this up in detail - but this is the general outline. Keep your source in source control, use makefiles to build and test, and use JUnit to integrate your testing results. There's a lot more to talk about, like strategies for speeding up the build by making things as parallel as possible, but I'll save that for the talk or a later blog entry.