Monthly Archives: August 2008

Securing the CruiseControl JMX interface

Securing the CruiseControl JMX interface(image taken from Roney’s photostream)

Jim Huang commented on the CruiseControl series page about an issue on his project:

We integrate our build with automation deployment and test running. The problem we have is how to prevent people from clicking the force build button by mistake. Anyone clicking the button will lead to another QA deployment. There is no access control from cruisecontrol. Do you have any solution for this?

Jim, you didn’t say if you were using the classic reporting application, or the new dashboard. And I’m not sure what operating system you’re using. So here’s some vague advice: you can block access to the JMX port. CruiseControl exposes all the state information and some commands via JMX over a TCP port. So securing that port is one way to stop accidental or deliberate messing with your CI server. On a Linux system you can block access to the port from certain machines using Iptables. Your options for Windows vary depending on your version that you have.

Just promise me that you’ll be careful, Jim.

Tagged

All build tools began with Make

All build tools began with Make

(image taken from slashcrisis’ photostream)

Today I’m just going to share a pet hate: poor target names in build files. Yes, that’s scratching the surface: there’s plenty of other things to get wrong in your build. But today’s gripe is target names. Here’s an anonymised example from a real project:

<?xml version="1.0" ?>
<project name="project" default="tests" basedir="..">

<target name="run-database-tests" description="Runs all database tests"
depends="foo-run-database-tests, bar-run-database-tests, baz-run-database-tests" />

<target name="produce-docs" description="Produces javadocs for the project">
<echo message="Building docs for ${common.dir}"/>
<run-javadoc dest="${common.dir}" source="${common.dir}/src/java/com/company/project/common/"/>
</target>

<target name="produce-diagrams" description="Produces diagrams for the project">
<run-springviz dest="${foo.dir}" config="${foo.dir}/config/WEB-INF"/>
<run-springviz dest="${bar.dir}" config="$baradmin.dir}/config/WEB-INF"/>
<run-springviz dest="${baz.dir}" config="${baz.dir}/config/WEB-INF"/>
</target>

</project>

What on earth would you do but run the database tests and produce the javadoc? Aren’t the verbs (like run and produce) superfluous here?

What if instead of typing

ant produce-docs


You could type

ant db-tests docs

It all makes sense when you think that most build tools are evolved from make. If you replace the examples above with make instead of ant, it seems to work.

Make was written in 1977 by Stuart Feldman at Bell Labs. Just about every Unix distribution ever includes make (or a bastardized version, but that’s another story). Microsoft implemented it. If you’re interested in build tools, have a play with make: it’s part of their heritage.

For me once I fool myself into thinking that the name of build tool is a verb, you don’t feel the need to put a verb in every target.

Still, I doubt that Apache Ant would have flown with a name that was a tribute to make (Jake? Ache?). And what they have called NAnt? Don’t go renaming your build tools on my account; but when you write a target, pretend you’re building with Make.

Tagged

Drive Mappings: argh!

Drive Mappings: argh!(image taken from William Hook’s Photostream)

There’s several things that are the root of all evil. Money, love of money, and mapped drives on Windows operating systems. This is especially true in a deployment context. Your deployment system should accept UNC paths for the servers it wants to know about.

Using Windows is one thing. Using Windows badly: inexcusable. Matt Lacey has a word or two on the subject.

Link

Oh lord, It’s hard to parse build files

Oh lord, It’s hard to parse build files

Nat Pryce left a comment on my post A real Build
Refactoring, in the wild:

IntelliJ can do some simple refactorings of Ant scripts: extract
property, rename target, rename property, etc.

But refactoring of Ant and Nant is very difficult because they have no
consistent syntax or semantics. They are just quick hacks that have
grown kludge by kludge into inconsistent pseudo-languages.

It seems I did Intellij a disservice when I said that it couldn’t do refactorings on build files. I downloaded the latest Mac release and had a try for about 20 minutes before I did the post. Refactoring didn’t happen. Maybe I should have spent longer. Sorry, Jetbrains. Thanks, Nat.

It does raise the question about our build tools. Maybe they’ll never have a decent editor. Nat’s multiple kludge theory would explain a lot. There’s a lot of editors that attempt to be your friendly build file editor, but not many come close. It’s been interesting watching Resharper 4’s Nant support evolve; it seems like it’s been hard work all the way.

For the time being, I’m reverting to the me of 6 years ago: I’m doing all my editing in Vim.

Tagged , ,

Five Software Build Patterns

Five Software Build Patterns(image taken from Laineys Photostream)

We live in a world of patterns. Some very clever people have been identifying and naming patterns in software for a long time now. In build and deployment, we’re just beginning. Here’s five:

  1. Aslak Hellesøy kicks things off with Immediate Test Failure Notification. If you’ve ever had to sit through a long CI build and then find out a test failed for some really crappy reason, you’ll like this one.
  2. Jon Tirsen introduces the Fast and the Full Builds. When your full build seems to take hours, you might break this one out.
  3. Sam Newman gives us the Checkin Gate. Otherwise known as the Checkin Dance. See also Movable Checkin Gate.
  4. The Build Doctor prescribes the Amnesiac CI Build. Oh, and he also scrawled down Captive Build Tool.
  5. Parumu gives us (among others) Binary Deliverable – one big monolith of deployment. Unsubtle but very predictable.

There must be more. If you have any suggestions I’d love to hear them. Comment here or drop a line to ‘medic@build-doctor.com’ …

Microsoft Web Deployment Tool

Microsoft Web Deployment Tool
(image taken from Scoble’s Photostream)

Microsoft are now offering a deployment tool to assist with the scary XCOPY-style deployments of .NET web applications. I’m old enough to have used XCOPY in DOS. It always seemed a little backwards to me: invest millions and millions in a language and platform to take on Java, and still use something that hasn’t changed since DOS to push your built apps around.

The features seem quite useful. It’ll allow you to compare both the source and target filesystems to only copy what has changed; GUI and command line I believe. It looks like it uses it’s own wire protocol to move assemblies about; no having to map drives or fiddle with UNC paths.

Props to my colleague Daniel Richardson who told me about this. I still owe him a beer.

Link

Continuous Integration – in a Box

Chad Wooley just announced “CI in a box” – a wrapper script that gets CruiseControl.rb bootstrapped and running. Cinabox joins a stable of ready-to-run CI systems:

Buildix which comes with the original CruiseControl
CI Factory which sets up CruiseControl.NET

All split down the various Java, .NET and Ruby factions. I wonder if there’s a Hudson based system in the works …

Link

Tagged

Your version control system is not a file system

If you find yourself needing to check binary files into your Version Control System, something isn’t right. Your VCS is optimised for tracking changes to source files. When you have multiple revisions of a source file, the VCS has stored the original file and the changes between revisions. This is good.

When you check in a binary, it doesn’t really do that. Most systems just keep a separate copy of the binary for each revision. So if you store 10 revisions of a 100 megabyte file, you can kiss a gigabyte goodbye. You might argue that disks are cheap. Unfortunately the cost of storage isn’t the issue. It’s the downtime to upgrade the server, it’s the admin overhead and risk of moving all of your data to a new disk. Sure you can do it.

Or you could stop using your VCS as the most expensive file system in your organisation.

(image from D. Meutia’s photostream)

Update: I wrote this in response to a contractor putting a 325mb file into my previous employer’s Perforce repository. I should qualify some of the statements in the post – for example there’s every reason to put small binary files in as part of your app. I think most people choose to check in binary dependencies into their projects rather than take the Maven/Ivy route.

Roll back a submitted Perforce changelist easily and quickly

Roll back a submitted Perforce changelist easily and quickly(image taken from goldberg’s photostream)


One of those key features of a version control system is being able to take a change that you submitted (maybe 5 minutes ago, maybe last week) and vaporize it. Like it never existed.

Actually, doing that is hard, but you can apply a change that is the exact mirror image of the one you want to roll back – a kind of antimatter for your change. This has always been a pain with Perforce. You can make it easier with scripts – Perforce publish instructions that involve awk scripts, which tend to make some of my .NET developer friends go pale.

Today, one of my developers broke the CI build and cheerfully went home. Other people needed to know that their checkins had worked, so his checkin needed to be reverted. So I was about to start the usual ritual of synchronizing to the old revision, deleting every file that had been added, adding every file that had been deleted. I got as far as googling the instructions, and found a page by Jim Tilander, who has written a script to do the ritual for you.

That’s not the clever bit. What’s clever is that he wrote the script to support the Perforce GUI client. So with a little bit of work, you can right click on a submitted change, revert it with a single click, and then submit your change to vaporize the old one.

To make this work you need to:

  • install Python ( I used Python 2.5)
  • put his script somewhere on your computer
  • tell your Perforce client about it.

It’s a really helpful script that will save me loads of time. Thank you Jim! (though errant developers may not thank you)

Link

Tagged

Evil Red Build Status Bear

Among other cool radiators at Last.FM.

Link