Monthly Archives: June 2011

#LondonCI, July 20

After a great meeting with Gus Power (watch the video) this month, we’re all set for LondonCI on July 20. David Farley from LMAX will be sharing his experiences with Continuous Deployment. Dave knows a thing or two about the topic, having co-written ‘Continuous Delivery’.

Meetup info here – don’t forget to register at Skills Matter …

DevOps – what the hell is it?

The guys at Urbancode[1], Accurev and Rally kindly asked me to do a talk on DevOps for their Agile Comes to You seminar. It felt like it needed to be a little different from usual. So I broke it up into 5 minute chunks and launched into each topic.

I covered 3 conflicting ideas about DevOps:

  • Devops is Systems Administration, but better
  • ‘Devop’ is a new role
  • DevOps is all about collaboration.

I was particularly happy with the slides.

The iterative approach to presenting worked quite well. We demonstrated this with my daughter breaking her collarbone the evening before the talk. Pro tip: a Paediatric Accident and Emergency department is no place to work on your presentations, unless you’re OK with the sound of screaming children). The next day I was a wreck and I think I would have fluffed it if it wasn’t for the chance to pause and take a one-minute break for questions after each ‘iteration’.

[1] They sponsor this blog.

Vendor news, 27-06-2011

Press releases, digested.

  • ThoughtWorks release an Agile ALM white paper [registration required]. I registered and read it; it’s aimed at your pointy-haired project management office boss.
  • Electric Cloud have teamed up with VaraLogix [they’re from Austin, TX] to do application deployment, extending the reach of Electric Commander. Everyone wants to be in this space now. It’ll be interesting to see if this generation of tools allows people to pave over the mistakes of the past. That might just help us look to the future.

#LondonCI Videos

In April, we kicked off with Chris Read.

In May, we had Paul Stack, Andy Parker, Tom Denley, Joe Schmezter [waiting for the video to be processed], and me.

Tomorrow, we’ll be filming Gus Power talking about Continous Deployment in the last mile. Remember to register if you’d like to come …


Simon Stewart on WebDriver’s build system

WebDriver creator Simon Stewart knows a thing or two about building code. So I was intrigued when he mentioned that he’d written a grammar for Rake, to enable building Java code.

Replacing Ant with Rake has been a compelling idea for some years now. Until now I wasn’t convinced that you weren’t going to have the same issues as Ant – poorly factored builds that rapidly evolve into a project specific DSL. This may change things.

The build system, or grammar as Simon calls it allows you to break a typical monolithic build file down into a collection of fragments. Each fragment can have one or more targets declared, and each target has some attributes. More at CrazyFunBuild.

Simon is undergoing an exceptionally drawn-out email interview on the process:

Your build tool is one of a few new players. What was your motivation for adding to the build gene pool? Were you scratching an itch, or do you have a broader motive?

Definitely scratching an itch. WebDriver started off as a simple java
project, but it quickly became obvious that it’d also be useful to
have language bindings for things like C#, ruby and python. I could
have settled on a separate build tool for each language, but there are
places where a Java component depends on a DLL (for example) Switching
build tools repeatedly when constructing a single logical unit seemed
wasteful, so I started looking around for a build tool that would
provide support for all the languages I wanted to use.

I failed, but settled on rake because it had poor support for everything 🙂

The next problem was that as the project grew, so did the Rakefile. It
ended up being obscenely long and increasingly fragile, and in the end
I was about the only person who would confidently hack around in
there. An obviously sub-optimal state of affairs. The first step in
fixing this was to break out common tasks into functions (because a
Rakefile is just a ruby script in disguise) This still left a pretty
large build file to deal with, so the next stage was to allow us to
break the script into pieces. The obvious issue is that if you do
this, where are paths relative to? The location of the top-level
Rakefile? Or the fragment of code in the subdirectory? Worse, it’d be
unwise to have duplicate task names (“test”) but detecting those while
writing a fragment of a build file would be troublesome at best.

At the same time, I like my builds to be as declarative as possible,
only breaking through the “fourth wall” to scripting when necessary.
Encouraging people to leave lots of little scripts that are the pieces
of a larger application as build files seemed like the worst way of
achieving that goal of “declarativeness”. So, I wrote a parser for a
sub-set of ruby (which mutated into a subset of python) using ragel
that parses build files and generates rake targets based on the path
to the build file and the name of the target in that file. It’s by no
means an original idea: the only thing I can take even a crumb of
credit for is the current implementation (and it’s pretty much
designed to work with selenium, so there are lots of corners cut in

By clearly defining the build grammar, there’s also a chance to
clearly define how paths are interpreted, so that neatly side-steps
that problem. I also provided an “escape hatch” so that you can call
out to other rake tasks as required. Better this is just a thin skin
around other build tools (the java parts delegate to ant controlled
programatically, and the .net pieces use visual studio) but it means
that anyone can read the build files and understand how the source
code, regardless of language, is transformed into a binary.

So, yeah, scratching the itch of “I want a single, declarative build
tool that allows someone not familiar with the other build tools used
to understand how the system works, and which can work with multiple
languages”. Right now, it’s specific to the project, and I’m
comfortable with that: I want to write a browser automation framework,
not a build grammar or (worse) a build tool. 🙂

To be continued


#LondonCI meetups, June and early July

June’s meetup is this Wednesday, 15th of June (sorry about the short notice) and features Gus Power of Energized Work:

This session will take a look at leveraging continuous integration techniques to deploy and operate software all the way to the end user, exploring some of the difficulties and gotchas along the way.

Gus is a great speaker, with great real world experience in delivering software. He has one of the finest bios I’ve seen in a while:

Gus Power is a hairy force of nature who’s always looking for better ways to figure out what the right stuff is and how do get it done.

Please register on the SkillsMatter website if you want to come. Meetup group info here. Pub afterwards is the Slaughtered Lamb.

For July I’m still trying to secure a speaker but in the interim, why don’t we go to the pub? Andrew Bayer of the Jenkins project is in town and wants to hang out with some Jenkins (or to be honest, any Continuous Integration) users. This will be at the Royal Festival Hall so no need to register with Skills Matter – but registering on the meetup group would help me get a handle on numbers.