This week I’ve been upgrading from CruiseControl to Hudson. CruiseControl has served well for the past eighteen months, completing hundreds of builds with only the occasional restart. Once configured with a couple of XML files CruiseControl is low maintenance, but my impression is that now Thoughtworks is offering a commercial product it is no longer getting as much attention as its competitors. Hudson in particular is an open source CI solution that has received good reviews, and with the need to configure new Maven projects I thought this a good time to switch.
The best way to use Hudson seems to be with a dedicated VM including any infrastructure required to test the project being built, in my case for example Java 6, Maven2 and a dedicated instance of Oracle XE. Although it is possible to simply start Hudson from the command line it makes more sense to install it as a service, and this is exactly what the Debian/Ubuntu package does. I use Hudson with a Nexus maven repository, with settings.xml stored in …/tools/_usr_share_maven2/conf/, so far it seems to be working well.
Since reading about database refactoring some while ago I’ve been seeking to adopt a tool to support automated tracking and application of database changes. The best known solution for this is LiquiBase (fka Sundog Refactoring Tool), with over 10,000 downloads of LiquiBase Core recorded on SourceForge as I write this. In order to adopt LiquiBase on an existing project, however, I was faced with replacing dozens of SQL DDL scripts with LiquiBase specific XML files. There is a generateChangeLog command, but it has limitations: for example it does not recognize the primary key of Oracle index organized tables, and the output is not arranged anything like the documented best practices.
Instead, for now, I have adopted a newer tool called dbMaintain, which was presented at a Belgian Java User Group last April (see below) and a ServerSide news article last July. dbMaintain provides similar functionality to LiquiBase, but instead of XML it simply passes through native SQL scripts using JDBC, making it much easier to adopt with confidence on an existing project. I did run into one known issue with setting the default schema, but I’m happy to say Tim Ducheyne responded to my emails and provided a fixed snapshot within days. I hope this project gains momentum, and I’m looking forward to the next release.
PS. Other less mature alternatives include SQL based Thoughtworks dbdeploy and Carbon Five’s c5-db-migration. Another custom XML based solution is MIGRATEdb. Sony Pictures Imageworks have ported ActiveRecord migrations to Scala and there is a relatively inactive port of ActiveRecord migrations to Groovy called Bering.