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”.

Sandi Baruco

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 I missed?



, ,




3 responses to “5 rules of continuous delivery”

  1. Mick Brooks Avatar

    Makes sense to me. (But then I’ve no real experience, and suspect I’ve been reading the same books as you.)

    It strikes me that, were you to use the rules as a recipe for starting out (or as levels for gauging, shudder, “maturity”) starting at the bottom and working upwards seems good. Though it’s hard to choose an order for “check in everything” and “automate everything”, so maybe a linear model doesn’t work?

    Was the ordering deliberate, and what do you think about the relationships between the rules?

    1. Seb Rose Avatar

      The ordering was accidental. I haven’t thought about relationships between the rules, though it’s certainly a good question. You could certainly make the case that it would be hard to automate “everything” until you’d checked “everything” in.

  2. Boris Modylevsky Avatar

    Yes, these rules sound reasonable to me. I found another rule or process very useful for continuous delivery improvement: Use the 5whys procedure when something goes wrong in the process. The final conclusion of such meeting would be a decision to automate something or to improve another part of automation.

Leave a Reply

Your email address will not be published. Required fields are marked *