Monthly Archives: September 2009

Clover plugin for Hudson

atlassian clover

The Atlassian guys emailed me a couple of days ago to tell me about their new Clover plugin for Hudson. What’s useful about it? You don’t need to write any Ant code to use Clover in your build – you install the plugin, enable it in your pointy-click Hudson configuration, and you’re off. You still need an Ant build, mind.

The plugin uses an Ant listener to spy on the build process and thereby work out what it needs to do. Also, it’ll trend your coverage over time.

It’ll work with Maven as well.


Photo courtesy of Jessica

Continuous Integration is an attitude

Question: How do we prevent integration pain?

Answer: Continuous Integration.

Well, duh. There’s no longer an excuse for integration pain. It’s been proven time and time again that the engineering practices of XP can work. Now we’re seeing the rise of a new issue: Continuous Indifference.

We were probably always prone to mediating communication with tools – the sheer number of issue trackers that exist are proof of that. With Continuous Indifference you can throw broken builds over the wall, and around the room. “Nope, it’s not my commit that broke the build”.

Combine that with:

  • an organisational addiction to email
  • a few other bloated tools
  • unmotivated developers – day rate contractors or disengaged permies

You have the perfect excuse for people to spent a pleasant afternoon debating who broke the build, and what to bill the debate to on their timesheet.

Screw that. It’s time to start again. Continuous Integration is people collaborating to achieve a shared goal. Continuous Integration is primarily a human practice. If you can’t do it without tools, you’re not really doing it. If your team don’t have the discipline to keep the build green, how will they do with the rest of your project?

It all comes down to attitude. Don’t be the last one to volunteer to fix the build. You’re a highly skilled software practitioner. Act like it.

Continuous Integration is an attitude.

Update: I’ve gone and echoed one of Jim Shore’s posts again.  Bugger.

Ant Contrib: the power and the pain

I got a comment from Errno on my last post:

“Everyone agrees that Ant Contrib means you’ve done something wrong.” why? is there any blog post/write-up describing this? thanks

I don’t know of any write-up. So I’ll make one. There’s a reason why some tasks are in ant-contrib and not the Ant tool proper: they don’t really fit the tool. The culprits that I have in mind are trycatch, for, and variable.

Now don’t get me wrong: these keywords would all be great in dozens of languages. Catching exceptions: Great! Iterating! Sweet! With a local variable! Sweeter!

But not in a declarative language. Because that’s what Ant is. It’s a declarative DSL for building Java code. Declarative programming allows you to present the facts to the language, and let it go do all the plumbing. So flow control in your Ant scripts aren’t needed, if you go about it the right way.

What’s more, properties are immutable. You need never test to see if a property is set before setting it. They did that for a reason: it’s subtly very powerful.

Perhaps it’s too subtle. Ant’s a powerful tool if you go with the grain. There’s a couple of other things to consider if you find yourself using the Ant-contrib stick:

  • Should you be using Ant at all? Remember, it’s a build tool. If you’re bending the tool to fit your needs, perhaps another will be better.
  • If you do need to get a bit more imperative, perhaps you could write an Ant task and share it with the world? Then we all get to enjoy a simple build.

Yes, I’m a build tool socialist. Want examples? Send me a snippet of build and I’ll tell you how I’d do it The Ant Way.

Image via merfam


Better Apache Ant Builds

Abstract: We did two CITCON sessions here; Joe Schmetzer suggested a show-and-tell about tools to reduce Ant bloat, and Ivan Moore wanted a general session on improving the quality of Java builds in general. During the conference, the two sessions merged. My plan was to sit in and tweet smart-ass comments. As I had my laptop open, they made me official scribe. Serves me right. Here’s my notes:

Joe: I have template Ant stuff to show you.
Ivan: I don’t like Ant. Is it just me?
(someone mentions how annoying it is when you have re-entrant AntCalls)
Chris Read and Julian Simpson: “Antcall is evil! Don’t use it!”
Ivan expands on his frustration with Ant: he builds something in Ant and then regrets it later. It has all the building blocks for the task at hand but he still finds it unwieldy.
Chris suggests orchestrating calls to Ant files using a scripting language.
Jeffrey Frederick suggests that writing custom Ant tasks is a good approach.

We discuss alternatives to Ant. None are found. Maven, Buildr and Gradle are mentioned but the broad agreement is that there’s always a trade-of between the convenience of those tools and the flexibility of Ant. [Please direct flames to the comments of this post. I really want to discuss this more]

JTF comments that the junior guy always gets to write the build. Why does the build get treated like a second class citizen? JTF suggests PowerPoint called object oriented build scripts, and a tool called EasyAnt.

Pavel from JetBrains mentions that IntelliJ have switched to Gant, and are very happy with it. I don’t believe that the all of the JetBrains Java projects have moved over.

Joe demonstrates his templates on a 9-inch netbook. This doesn’t really work out as we can’t get the projector going, so he outlines it. This is hard to transcribe.

Joe: Don’t cut and paste Ant scripts. Import predefined targets instead. Well defined targets can be reused. This leads to tiny Ant scripts for each project. Joe’s projects end up having a 10-15 lines of Ant script. Joe has released this all at Ant Script Library.

Joe explains the targets that he uses most frequently – the usual suspects of compile, test, etc. He’s integrated a lot of static analysis tools into the library (he rattled off a huge list, which I failed to capture) – that’s a win.

Joe‘s abstracted SCM and release targets nicely, by the sound of it.
Paul Duvall asks if they are targets or macrodefs. They are targets.
Joe hates code generation so doesn’t use it in this toolset. Healthy discussion of script generation.
There’s clear parallels with maven and the strongly defined code tree.
You can buy my refactoring ant article at at good second hand bookstores.[link]
People go against the grain of the tools.
Everyone agrees that Ant Contrib means you’ve done something wrong.
. JTF suggests that string literals are okay in builds.

How do you test build stuff? JTF suggests:

  • a test project
  • writing junit tests

Pavel and friends at JetBrains use personal builds to test all this.
Andy Parker asks how much container stuff and deployment you should use.
We all agree that running the production deploy in CI is the business.
Ivan: how do you deal with the devs on windows/prod on unix business
VM’s are the saviour of the windows/unix divide.
The windows/unix divide is a perennial issue.
Jetbrains use build agents to try and flush out issues.

JTF: Ant builds can suck when:

  • junior people write them
  • there’s no refactoring
  • they are treated as a second class citizen
  • imperative vs declarative
  • code ownership: if you touch it, you own it. Hence, nobody will touch it.

We had a vigourous discussion of dependency management. Chris asks for discipline. Andy points out that you can end up with integration hell. Maven’s release plugin can allegedly resolve dependencies too late in the QA process and end up changing the release candidate. Chris complains that it can be hard to rebuild later when you depend on the latest version of a dependency. Joe did his own wrote-up here.

PS: I’ll add some links back to the various people mentioned here

Tagged ,

CITCON Europe 2009

I’ll sporadically be tweeting about the conference throughout the weekend.


Lots of Run Code Run news

I got a mail from Rob at RunCodeRun last week. Lots going on.

Last night we pushed out our latest commercial plan that a lot of folks had been asking for – a $19 a month ‘basic’ plan with support for 3 private projects. Previously our lowest cost plan was $75 a month, so we feel like RCR is within reach for much smaller teams now.

Seems that CI tools (and services) launch with a high price ticket but there seems to be most demand for reasonably priced products.

Last week we added support for Postgresql, and the week before we added Campfire notifications.

Another sound couple of features.

Next week will be a huge announcement for us — we will be adding support for building against Ruby 1.8, 1.9, and JRuby for the same project. We’ve already seen this as a huge win for open source or projects that are transitioning to 1.9 for the speed increase.

You heard it here first. Testing against 1.9 is a smart thing to do, but I love the JRuby feature. Getting over the ‘It’s not Java’ hurdle in some organisations could be important. Though this could pave the way for WebSphere Application Server, DHH Edition.

Oh yeah, we now have java and ant builds also working across RCR. Its not quite a first class citizen, but its very close

And he saves the best for last. Will they be selling these like hotcakes? I think they’ll sell a lot; but a lot of organisations will need to raise their game to take advantage. Some might even have a crack at it.

the industries first and only open-source continuous integration solution


SecureCIâ„¢ is the industries first and only open-source continuous integration solution. By leveraging best of class open source products for source code control, build management, automated testing, security analysis, defect tracking, and project management, Coveros is able to provide a turn key solution for those who wish to begin leveraging the benefits of continuous integration.

Umm, how about Buildix [2006] or CI Factory [earlier than that]?

Anyway, it’s a bundled Hudson. Looks like they put some effort into assembling all the tools around it.

Linkage, August 3

There’s been some tabs festering on my browser for a while. Here, you have them.

  • Staycation this year was Cornwall. I can strongly recommend the Porthcurno Telegraph Museum.
  • This Neal Stevenson Wired article is a fascinating read on the subject.
  • Martin Fowler writes on Feature Branches
  • PJ writes about Martin’s writing.
  • Carlos writes about the Tracer Bullet application. Oh, how this would have resolved some pissing matches in the past. Were we performance testing the infrastructure or the app?
  • Checklist for making an Agile startup. Or any startup.
  • And here’s an Agile Backlash post. Just be Careful.