Continuous Delivery and DevOps are interdependent, not equivalent
Since the publication of Dave Farley and Jez Humble’s seminal book on Continuous Delivery in 2010, its rise within the IT industry has been paralleled by the growth of the DevOps movement. While Continuous Delivery has an explicit goal of optimising for cycle time and an established set of principles and practices, DevOps is a more organic philosophy that is defined as “aligning development and operations roles and processes in the context of shared business objectives“, and gradually codifying into principles and practices. Continuous Delivery and DevOps possess a shared background in agile methods and Lean Thinking, and a shared desire to eliminate Waterscrumfall silos – but what is the nature of their relationship?
In Continuous Delivery, practitioners such as Jez Humble have warned that organisations require “a culture that enables collaboration and understanding between the functional groups that deliver IT services“, which refers to the culture-centric principles – Continuous Improvement, Done Means Released, and Everybody Is Responsible – that reduce handover delays between siloed teams. DevOps provides an implementation strategy for these principles – its emphasis upon “the integration of Agile principles with Operations practices” aligns Development and Operations working practices and encourages cooperation. However, these principles can be also implemented independently of DevOps – for example, an organisation might forego a QA team in favour of mandatory Development support for production releases, as at Facebook.
In DevOps, one of the four key areas described by Patrick Debois is Extend Delivery To Production. The intention is for the delivery mechanism to act as a focal point for collaboration between Development and Operations, resulting in improved speed/reliability of releases and a sense of shared responsibility for production systems. Continuous Delivery offers an implementation strategy for this key area – a deployment pipeline provides a shared one-button workflow, encourages the emergence of a shared codebase and toolchain, and facilitates a release cadence that minimises change sets and the risk of failure. However, it should be noted that Extend Delivery To Production could be accomplished without Continuous Delivery – for example, a push-based Continuous Deployment mechanism might underpin the value stream instead of a pull-based pipeline, as at IMVU.
From the above we can surmise that Continuous Delivery and DevOps are interdependent, but the inherent fuzziness of the DevOps philosophy allows different interpretations of the relationship. For example, Jeff Sussna recently contended that “delivering software as service makes operations an explicit part of the customer value proposition… customers view functionality and operability as inseparable aspects of service” and that by defining DevOps “not in terms of how IT structures itself, but rather in terms of what customers expect” we can say “DevOps IS Continuous Delivery“. While it is an interesting approach to couple DevOps to customer expectations, the commonly accepted definitions focus upon internal organisational change in order to meet business objectives, which may or may not include operability as a first-class concept. It is evident that SaaS customers will have explicit operability requirements, but for many organisations the reality is that customers explicitly expect functionality and timeliness while implicitly expecting operability. For example, Jeff uses a restaurant review metaphor to describe the combined value of functionality and operability (“the food was great but the service was terrible“), but restaurant customers cannot observe back-of-house operability and will likely only comment upon front-of-house operability if it impacts upon functionality and/or timeliness.
Jeff also makes a comparison of nomenclature, suggesting that for agile development and Continuous Delivery the name describes the value… in the case of DevOps, the name describes the implementation, not the desired outcome“. Surely the desired outcome of DevOps is expressed in the portmanteau – Development and Operations teams seamlessly working together to deliver value-adding features to the customer.
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.
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!