magpiebrain

I’ve been assimilated

Yes, it’s true. The all pervading air of Mac Mini hype has finally brought me to my knees – no longer can I hope to stand up to such a barrage of “but it’s so small” or “but its so cheap!” and most importantly “but it’s so cute – you can buy one if you want, but I get to use it!”. The current plan is to twin it with Elgato’s EyeTV 410, and a 20” Apple Cinema display. Sure, after I add that, a DVD burner, more memory, and an Apple Care package it isn’t looking quite so cheap, but what the hey, it is damn cute – those comparing it with similar priced options from Dell are completely missing the point if you ask me.

Automating the build pipeline

As described before, the build pipeline is a series of builds, each performing some specific task. The result of one build becomes the input of the next.

Many people see the pipeline describing only those parts which can be automated – as such, you’ll often see the pipeline end far short of production ready code – once it’s got past the final automated barrier, the code then plunges into a grey mass of manual, distributed, often ad-hoc processes. For the build pipeline to work at all, it has to be continued all the way to producing production ready code. That is not to say the whole pipeline should be automated.

An introduction to build pipelining

Update 1: Fixed arrows on two of the images – damn Visio…

Update 2: Tweaked the final diagram to show build artifacts being checked in and retrieved

Lets look at a fairly simple build.

Enforcing test coverage in the build

First off, I’d like to say that 100% test coverage does not mean that your code is bug free – it simply means you haven’t written a test good enough to find a bug. Your tests could even cause all of your code to be executed, but not have a single assert anywhere.

How much assurance you can gain from having unit tests depends on the quality of the test itself, and on how much of your code is covered by tests. Tools like Clover and Emma can tell you what code gets checked as part of a test run.

Speeding up the build

Update: Fixed typo

Introduction

Slow builds are perhaps the most irritating thing for a developer. Having worked on two projects now with +30 minute continuous integration builds, it’s something of a personal bugbear for me. Before we look at some ways to speed up the build, I thought I’d start with my definition of what a build is�

What is a build?

Quite simply a build is the process of taking source code and producing some artifacts. The artifacts could be a war file, some test output or even a full blown desktop application. A project might (and probably should) have several different builds for different purposes – one for developers, QA, production etc.

End of year roundup

A quick run-through of the least year at magpiebrain is in order I think:

• January saw me looking at IoC and getting far more interested than I should of. I also found del.icio.us, and the web was a good place again.
• February and I was playing with Spring, XWork and TDD. My article on IoC goes up at java.net – shame on me!
• March and I was writing up stuff on regular expressions before I started my current job.
• April saw me finally sort out permalinks and send a new site design live. A long commute also saw some longer than average posts.
• May and I was playing around with a few things I never came back to.
• June came around and I was playing with Naked Objects, I upgraded this site to Movable Type 3, and I went to Glastonbury.
• July and I started looking beyond the crap a bit more, and purposely started writing things to piss people off. It kind of worked…
• August was a very slow month, as my new client was sapping all ability to even think about interesting (or otherwise) topics.
• September was another slow month, for much the same reason, but I did get to escape from being build-bitch long enough to code for a couple of days, so it wasn’t all bad.
• October – ditto
• November – ditto. It seems being a build-bitch isn’t something which promotes frequent blogging.
• December was much better, thanks in part to managing to make it to a Java meet-up in London, work finally generating some subjects which I thought blogging about would be of interest, and I found out I was off to a new client in the new year.

So happy new year everyone – roll on 2005…