Hudson - great for when you need a lightweight CI tool in a hurry
On a recent project a colleague recommended Hudson which turned out to be a very good call indeed. The team was genuinely impressed. Despite the tagline claiming it is an "Extensible continuous integration engine" - seriously Hudson people, drop the "engine" - that smells like a programming vapourword. Anyway, continuous integration tools seem to be aligning themselves into two camps, big fat do everything ones, and small neat lightweight ones. Hudson is now firmly at the top of my list of the second flavour.
So this is why it is well suited to short, dare I say agile, projects:
- Trivial installation – the released package is a war file, so you drop it in your web container of choice and away you go.
- Configuration – going with the lightweight rapid theme, there is not much to configure. However, Hudson scores with a really intuitive gui. No need to read the docs.
- Feature set – it had everything required for the tight timescale project I was working on – namely subversion integration (naturally), cron (quartz I guess) style scheduling, rss feeds for build results, JUnit report rendering, and a really sweet unix tail style build output watcher.
and this is what is not quite perfect
- Missing a couple of features, such as support for alerting build status over chat, and delayed commit.
- Although there seems to be a decent swell of support for Hudson, and it has an open extension system, there just aren’t that many compelling extensions yet.
- No support that I could find for adding in code coverage reporting.
- A successful build shows a blue rather than red traffic light. That’s just confusing. Like is blue good or bad?
Really though, I am just splitting hairs. Hudson was very impressive.
Labels: continuous integration
subscribe by email or rss
Java application config choices
I took some good-natured jibing on my last project about the level to which I wanted to make the application configurable. My innate pedantry meant that I was driven to throw as much of the configuration and even logic into external files. Frameworks like Spring positively encourage this - why would you ever have a hard-coded static constant, when you can inject a value from xml? And why stop there - why not config your Spring config files with a PropertyPlaceholderConfigurer... Well, my colleagues have made me think a bit more about this approach. Clearly, there is some config data that no-one is quibbling about - database credentials for exmple, simply do not live hard coded into the application. But what about other meta data? Like say a number format pattern? Or an SQL string?
There are lots of choices for where metadata can reside, and picking the appropriate one is key. Databases and properties files are great for config that often needs changing on the fly. For example, the number format for a column in an online report. However, they add a level of indirection during development which is anooying as the data is physically separated from the source. They are also not well suited to refactoring, although IDEs ease some of the pain these days.
Annotations are at the other extreme as they are bound to the source. They're appropriate for a different category of metadata - when your config drives the code's core functionality. The classic example is a SQL (or an object query language) string which is well suited to living in annotated methods in DAOs. There is no point having it in an easliy-changed properties file because when you change your SQL you are fundamentally impacting the behaviour. That is not a runtime activity. However, annotations are more verbose to create. Moreover they are easily abused and overused resulting in bloated, messy code.
As an aside, and a great example of annotation abuse, I really don't like JUnit 4's @Ignore - if the test is broken then fix the damn thing! That is just encouraging sloppiness. It is even worse than commenting out a broken test as it kind of looks official - like you somehow meant to do it. As much as I hate to admit it, at least a chunk of commented out test code is a big red flag that shouts at you to go back and get the thing to pass.
So to sum up, the choices available in Java are increasing all the time. Spring for example ships with more and more annotations. In addition support is there for bean wiring by xml, properties files and programatically through the api. In a slightly obtuse way, their new dynamic language support can be thought of as config - you can certainly use it to inject new bahaviour at runtime. The choice can only be a good thing (I don't want to be forced to use EJB 2 deployment descriptors ever again). It just means I've got to think more carefully about where application metadata should live and not just dump anything that looks like config into properties files.
subscribe by email or rss
