CONTINUOUS DELIVERY IS a set of principles, patterns,
and practices designed to make deployments—whether
of a large-scale distributed system, a complex production
environment, an embedded system, or a mobile app—
predictable, routine affairs that can be performed on
demand at any time. This article introduces continuous
delivery, presents both common objections and actual
obstacles to implementing it, and describes how to
overcome them using real-life examples.
The object of continuous delivery is to be able
to get changes of all types—including new features,
configuration changes, bug fixes, and experiments—
into production, or into the hands of users, safely
and quickly in a sustainable way.
It is often assumed that deploying software more
frequently means accepting lower levels of stability and
reliability in systems. In fact, peer-reviewed research
shows that this is not the case; high-performing teams
consistently deliver services faster and
more reliably than their low-perform-
ing competition. This is true even in
highly regulated domains such as fi-
nancial services and government.
This capability provides a competitive advantage for organizations that
are willing to invest the effort to pursue it. It allows teams to deliver new
features as they are ready, test working
prototypes with real customers, and
build and evolve more stable, resilient
systems. Implementing continuous
delivery has also been shown to reduce
the ongoing costs of evolving products
and services, improve their quality, and
reduce team burnout.
While continuous deployment, the
practice of continuously releasing
every good build of your software, is
mainly limited to cloud- or datacenter-hosted services, continuous delivery—
the set of practices described here that
enables continuous deployment—can
be applied in any domain.
A number of principles and practices form the continuous delivery canon
(find out more at https://continuousde-
Common Objections to
While people may know about continuous delivery, they often assume that “it
won’t work here.” The most common
objections cited are these:
˲ Continuous delivery is unsuitable
when working in highly regulated environments.
˲Continuous delivery is only for
˲Continuous delivery practices
can’t be applied to legacy systems.
˲ Continuous delivery requires engineers with more experience and talent
than are available here.
Here, I examine and debunk these
claims, followed by a discussion of the
real obstacles to implementing continuous delivery: inadequate architecture
and a nongenerative culture.
Working in highly regulated environments. Objections to the use of continuous delivery in regulated environments
Will It Work Here?
Article development led by
It’s not magic, it just requires continuous,
daily improvement at all levels.
BY JEZ HUMBLE