Summary: many people confuse continuous deployment (pushing changes to live systems many times per day) with Continuous Delivery (reliable software releases through build, test, and deployment automation). Here is why I think that Continuous Delivery is the more fundamental practice.

(Update 1, 2017-11-02: clarified ‘continuous deployment’ and the on-premises context)

I work with many organisations that build many different kinds of software: cloud-hosted online services, internal business systems, data-driven systems with ETL, embedded systems, IoT devices, (and to a lesser extent mobile apps). Some practices and approaches consistently work well across these disparate kinds of software types:

• A focus on software operability (which is why I’m co-authoring a book on operability 🙂 )
• Continuous Integration
• Continuous Delivery as described by Jez Humble and Dave Farley in their book

Practices that are not applicable across all the different modern software domains include DevOps and continuous deployment. However, many people seem to get confused between Continuous Delivery – the set of practices that together provide “Reliable Software Releases through Build, Test, and Deployment Automation” – and continuous deployment (pushing changes many times per day to a live system), which is really a niche practice applicable only to cloud-connected software systems under the close control of the organisation building that software. Much modern software does not fit into this mould.

Continuous Integration, Continuous Deployment, Continuous Delivery

Let’s characterise the differences between three related but distinct practices:

• Continuous Integration: Build & test code on every commit to version control, at least every day
• Continuous Deployment: Push changes to live systems as soon as the tests pass (maybe many times per day)
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Of these, Continuous Integration and Continuous Delivery are fundamental to safe, reliable software releases, but continuous deployment has limited (if popular) applicability.

Update (2017-11-02): Timothy Fitz pointed out that this usage of “continuous deployment” is is different from the one he coined many years ago at IMVU:

Let’s visualise these differences using diagrams from the book Continuous Delivery with Windows and .NET from O’Reilly that I co-authored with Chris O’Dell in 2016:

The practice of continuous deployment works only some specific situations such as public cloud where the organisation building and running the software either owns or has direct access to the live systems. We cannot continuously deploy to customer-owned on-premises infrastructure or to embedded devices such as printers or machine microcontrollers.

However, the set of practices from the Continuous Delivery book by Humble & Farley are applicable and hugely useful in all these situations (cloud, on-premises, embedded) and more:

Some of these key Continuous Delivery practices include: Every Check-in Leads to a Potential Release; Keep Everything in Version Control; Check In Regularly to Trunk; Done Means Released; Never Go Home on a Broken Build; and so on. Many of these practices are really about team and engineering discipline, so it’s not surprising that they have general applicability than “push changes to live as soon as the tests pass”, which is effectively what continuous deployment entails.

Let’s be clear: continuous deployment is a really useful and enabling practice for certain specific situations, and drives all kinds of good engineering behaviours like metrics-first development and “You Build It, You Run It“; it’s just not relevant in many software delivery situations.

The descriptions of Continuous Delivery practices in our book Continuous Delivery with Windows and .NET are actually applicable and useful outside of a Windows/.NET context: the book is actually core reading material for the Software Systems Engineering course at University College London (UCL) in the UK. Don’t be afraid to share with people who work with Java, Python, or Linux 🙂

Update (2017-11-02): in the diagrams above, the “on-premise” model refers to situations where we’re delivering software to a customer’s private on-premise systems to which we have no access. Clearly, if we own or have direct access to on-premises infrastructure, we should be able to deploy continuously to that (subject to decent tooling). Thanks to John Allspaw for calling out this ambiguity!

Clearly, HP cannot expect to use continuous deployment push firmware updates multiple times per to printers around the world – that would be commercial madness and physically impossible. However, by adopting & evolving practices close to Continuous Delivery, the HP teams were able to transform the quality and viability of their printer firmware software.

Closing: Continuous Delivery is fundamental to all software development, but continuous deployment is just a useful niche

Although continuous deployment is a great practice for some software systems, Continuous Delivery is the more fundamental set of practices that apply broadly across different kinds of software (cloud, on-premises, data-driven, IoT, embedded, mobile, etc.).

Further reading

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble & Dave Farley
• A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware by Gary Gruver, Mike Young, and Pat Fulghum
• Continuous Delivery with Windows and .NET by Matthew Skelton and Chris O’Dell
• Team Guide to Software Operability by Matthew Skelton and Rob Thatcher