2 comments on “Continuous Delivery != DevOps”

  1. Steve,

    My responses to some of your particular points:

    1. In the first paragraph, your definition of Continuous Delivery is simple and easy to understand, while the DevOps definition is long and hard to follow. That is part of my point. When I read various DevOps discussions, though, they commonly point to optimizing cycle time as the desired outcome. In other words, CD and DO seem to have the same goal.

    2. Re Dev&Ops vs. Dev&QA, I think DevOps creates problems by being too restrictive in scope. People have asked “do we need DevSecOps”? I personally think we need “DesDevQASecOps”. The point is that we need collaboration among all groups and people involved in delivery software service. Naming it after an implementation of part of the solution IMO leads to difficulties.

    3. I don’t see the value in differentiating between explicit and implicit expectations. Even within the functionality realm there are implicit expectations (ease of use, good design, etc.) Agile has taught us that many supposedly explicit functionality expectations really are implicit: users aren’t able to articulate them until they see them missing.

    4. I don’t agree that the desired outcome of DevOps is expressed in the portmanteau. DevOps tells us that dev and ops are working together. It doesn’t say anything about why. You had to add that part: “to delivery value-adding features to the customer”. That’s exactly what Continuous Delivery is about. So now you’ve (IMHO) conflated an albeit powerful implementation detail with an overall practice/goal.

  2. Hi Jeff

    Thanks very much for that.

    I think definitions of DevOps will remain fuzzy, at least until the DevOps Cookbook (http://www.realgenekim.me/devops-cookbook/) comes out. The authors themselves acknowledge that fuzziness – Gene Kim says of the book “one of the valid complaints about DevOps is that it’s difficult to describe what it is. Currently, DevOps is more like a philosophical movement, and not yet a precise collection of practices, descriptive or prescriptive”. That’s admirably honest.

    For me, DevOps is a philosophy that started out as a desire for Development and Operations to collaborate more closely together, and has since extended towards the goal of Continuous Delivery – streamlining the value stream of an organisation, by tackling any organisational silos found – in http://java.dzone.com/articles/codifying-devops Patrick Debois refers to these as DevOps Lite and DevOps respectively. The difference between “DevOps Lite” and “DevOps” feels like a big communication gap.

    I’d argue the distinction between explicit and implicit expectations is important – between what a customer will and will not pay for, as evidenced by many organisations sadly funding operational requirements as opex against capex-funded functional requirements. That said, we can shift customer perceptions and it’s our responsibility to communicate to customers the benefits of continuously improving operability, not just functionality.

    I think there is tremendous value in Development and Operations working closely together, even if (gasp!) it does not benefit the value stream, hence my affection for the DevOps name. As an occasionally siloed developer there may be some self-bias there, of course!

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>