AK's weblog

Dear Sam,
Although what you describe comes quite close to CI, it isn't. Unless you compile the code and run the test suite in a clean and neutral build environment, you can never be sure that the changes you're about to commit really do integrate properly. Even if you do a svn/cvs update (or the equivalent command of your favorite SCM) before you compile, run the tests and commit, you'll never know whether it compiles in other build environments. Perhaps you've forgotten to add a file to be committed, perhaps you've relied on certain specifics of your local system when tweaking something on the Makefiles. People make these mistakes all the time, and that's why we shouldn't rely on people running test suites locally.

That's what CI system like CruiseControl or Hudson are there for: they rebuild the software and run the test suite in a clean environment (ideally) whenever a commit is done, in continuous iterations, automatically, without any manual intervention by the programmer. With such simple little helpers combined with some notification, such integration mistakes or any other regressions that can be caught with the existing test suite wouldn't go unnoticed. Hey, you could even send notification emails about build and/or test failures (including their recoveries) to a public mailing list, which would dramatically increase the visibility of such automatized efforts.

If you already do so, I apologize for my possibly rude tone, but your article suggests that you don't.

Gerade hab ich Hudson ausprobiert, es hat sich als wirklich nettes Continuous-Integration-Tool herausgestellt. Primär interessiert bin ich natürlich an Continuous Integration für newsbeuter, gleichzeitig dient diese Evaluierung aber auch küntigen potentiellen anderen Einsätzen.

Das Setup von Hudson ist einfach: das .jar-File von der Website herunterladen, "java -jar hudson.jar" ausführen, und nach kurzer Zeit ist das Hudson-Webinterface schon auf localhost:8080 verfügbar (alternativ ist das Deployment in einem Servlet-Container auch möglich, aber sowas hab und brauch ich nicht). In diesem Webinterface erstellt man dann einen neuen Job, bei dem man angibt, as welchem CVS- oder SVN-Repository der Code ausgecheckt werden soll, wie ein Build getriggert werden soll, welche Kommandos ausgeführt werden sollen (bei nicht-Java-Dingen ist das Ausführen von Shellkommandos am zweckmäßigsten, um Buildtools wie make sowie das Ausführen von Unit-Tests zu steuern), und wie die Email-Notification ablaufen soll. Dann ist der Job schon einsatzbereit, und man kann einen Build starten, um zu testen, ob der Build auch korrekt abläuft.

Abgesehen von der Abhängigkeit von Java ist Hudson wirklich sehr angenehm, und ich kann es voll und ganz weiterempfehlen, vorausgesetzt, man setzt kein exotisches SCM ein (CVS und Subversion werden unterstützt). Auch für künftige Projekte werde ich es sicher einsetzen.