Monday, July 30, 2007

The pipeline of doom

Simon wrote recently about the Build Pipeline. His enthusiasm for the technique is infectious, but I have to add a note of caution. The big idea is to reduce the feedback cycle for developers ("the unit and db tests passed on CruiseControl, our checkin looks okay") while still allowing slower automated acceptance or regression tests to run afterward. Of course, the entire team needs to treat the second build with as much reverence as the first.

I haven't always found that to be the case. So I wouldn't recommend this technique unless the team already has enough discipline to keep a Continuous Integration build green, for starters.

The other aspect of the pipeline that I find troubling is this: by not forcing the developers to sit through the functional tests before they check in their code, you prevent their fantastic brains from reflecting on improving them. If people are feeling the pain of running them, they have a good motivation to fix them. Those tests ought to provide the biggest bang for your buck: unless you're careful you could be running poor tests dozens of times a day.

Don't simply push those tests down the pipeline, but fix them where you can, and keep the feedback loop as fast as you can for the entire team. After all, there's no silver bullet.

Sunday, July 08, 2007

Ha ha! Take that, ${temp.dir}!

I don't often celebrate removing weird things from the Ant build on projects - it's part of my job. But this one was special. ${temp.dir} used to point to the /tmp directory on the build servers. Several targets would read or write artifacts into that directory. ${temp.dir} had probably had a very simple job when it was conceived, but over time things had been twisted to do more with it. It bugged me.

Over some weeks it had been a part-time hobby of mine to make small changes to the build so that I could finally remove ${temp.dir}. And recently I actually did remove it. I find that by finding something that irritates me, and reflecting on a way to remove it, I end up simplifying things in the process. I often end up breaking things if I jump in and fix it; so I force myself to make small steps in fixing the problem until the day comes that I can remove that-which-bugs-me with confidence. This usually has the happy side effect of making the build more robust and easier to understand.

Now I'm looking at cruise-properties.xml. It'll have to go.