Monthly Archives: February 2014


5 rules of continuous delivery

Inspired by Sandi Metz’s BaRuCo 2013 presentation “Rules” (which you should watch if you haven’t yet) I started thinking about whether there were some  rules that might be useful in the continuous delivery domain to “screen for cooperative types”.

I came up with these as a starting point:

Check in everything – we’re used to putting source code in version control, but we’re often less good at configuration management. Do you control your test data? Your database scripts? Your operating system patch level? If not how can you be sure that the environment you provision tomorrow will be identical to the one you provisioned last week?
Automate everything – “to err is human”, as the saying goes. Any manual process is susceptible to failures, so get rid of as many as you can. Some continuous delivery pipelines still have manual approval steps in them as part of the process, but the presence of the human is not functionally essential.
Continuous != occasionally – the more we do something, the easier it gets. One of the reasons to do something continuously is to decrease the cost and remove the fear. If it “costs too much” to deploy often, then work on reducing the cost not reducing the frequency.
Collaborate – people are not plug compatible. To get the most from the different people in the organisation we need to work together. For me, this was one of the major “innovations” of devops – no more ‘us’ and ‘them’, just ‘we’.
One step at a time – it’s hard to do everything all at once, which is why we iterate in software development. Continuous delivery is no different – don’t expect everything to “just happen”.

Do these make sense to you? What essential ingredients have […]

By |February 28th, 2014|Agile, Continuous Delivery, Practices|3 Comments

Continuous delivery – the novel

I find myself recommending the same books over and over again. When speaking to techies I invariably recommend GOOS; when speaking to managers The Mythical Man Month or Waltzing With Bears. Over the past year or two, I’ve also pointed a lot of organisations at Continuous Delivery by Jez Humble and Dave Farley. It’s an important book, but I think it could have been shorter, and that’s an important consideration for the target audience. If you consider the other books I recommend that weigh in at 384, 336 and 196 pages respectively, Continuous Delivery extends to 512 and it feels longer. That’s not because it isn’t good – it is – but because it is detailed and quite dense.

Last week I finally heeded Liz Keogh’s advice and read The Phoenix Project (“a novel about IT, Devops and helping your business win”). In terms of prose style, it doesn’t compete with Liz’s own efforts, but it is very readable and does a great job of getting some quite tricky concepts across (Lean, Theory of Constraints, The Three Ways). The authors acknowledge their debt to Goldratt’s The Goal, and indeed they are ploughing the same furrow, but in the field of software. Amazon says the print copy is 343 pages long, but I read it on the Kindle and it felt shorter than that.

The reason I’m adding this book to my recommended list isn’t just because it’s short and readable. It’s because it makes some very frightening concepts very easy to digest. I didn’t know how to explain quite why I liked it so much until I found myself reading a Venkat Rao post this morning, where he describes how we change our minds:

You have to:

1. Learn new […]

By |February 24th, 2014|Agile, Practices, Systems|1 Comment

Teaching TDD (TTDD)

There has been a flurry of discussion about how to teach TDD, sparked off by a recent post from Justin Searls. In it he lists a number of failures that range from “Encouraging costly Extract refactors” to “Making a mess with mocks” all of which distract attention from the concept that “TDD’s primary benefit is to improve the design of our code”. He concludes by suggesting that once you have written a failing test, rather than get-to-green in the simplest way possible you should “intentionally defer writing any implementation logic! Instead, break down the problem by dreaming up all of the objects you wish you had at your disposal”. In essence, design the elements of the solution while the first test is still red.

It’s an interesting post that raises a number of issues, but for me its value lies chiefly in opening the subject up for debate. The introduction is particularly pertinent – just setting a class a bundle of katas to do does not, of itself, encourage learning. The pains experienced while doing the exercise need to be teased out, discussed and have alternative approaches described. If you don’t hear the penny drop, then it hasn’t dropped.

Pitching in with characteristic vigour and brimstone came Uncle Bob with a robust rebuttal containing both heat and light (though some have been put off by the heat and never got to the light). Bob makes some good points regarding the fallacy of writing tests around extracted classes, the tool support for extract refactoring and the central place of refactoring in the Red-Green-Refactor cycle.

By the conclusion, however, Bob has switched tack. He states that while refactorings are cheap within architectural boundaries, they are expensive across them. Whether he’s right or wrong […]

By |February 4th, 2014|Practices, TDD, Unit testing|2 Comments