Continuous Delivery

What Is Continuous Delivery?

Continuous delivery answers a business question more than a technical one: can we ship this today if we decide to? When the answer is always yes, releasing becomes a product decision instead of an engineering project.

The term comes from Jez Humble and David Farley's 2010 book Continuous Delivery, which described the deployment pipeline: an automated sequence that takes every commit from source control through build and testing to a release-ready package. A change that passes every stage can go live with a single approval.

Continuous delivery sits on top of continuous integration, where developers merge small changes into a shared branch several times a day. Continuous integration proves the code fits together. Continuous delivery proves it is ready for production.

It is often confused with continuous deployment. The difference is one step: in continuous delivery a person decides when a release-ready build goes to production, while continuous deployment releases every passing change automatically.

Why Does Continuous Delivery Matter?

Continuous delivery matters because it turns releases from rare, risky events into routine ones that cost almost nothing to repeat.

• It shrinks each release. Teams that can release any day ship a handful of changes at a time. When something breaks, there are only a few suspects, and rolling back removes one small change instead of a month of work.

• It lets the business pick the release date. Marketing launches and customer commitments stop depending on when the next scheduled release leaves.

• It shortens the path from idea to user feedback. A feature that reaches users days after it is built can be measured and adjusted while the team still remembers why they built it that way.

How Does Continuous Delivery Work?

Continuous delivery works through a deployment pipeline that every change passes through on its way to a release-ready state.

• Every commit triggers the pipeline. A push to the main branch, or a merged pull request, starts an automated build. Nothing enters the release path through a side door.

• Automated tests gate each stage. Fast unit tests run first, followed by integration and end-to-end suites. A failure at any stage stops the change from moving forward.

• The same artifact moves through every environment. The pipeline builds the application once and promotes that exact package from staging to production. Rebuilding for each environment would mean production runs something that was never tested.

• Environments are defined as code. Infrastructure-as-code tools such as Terraform describe servers and configuration in version-controlled files, so staging and production do not drift apart.

• Release takes one approval. Once a build is marked release-ready, deploying it is one click. Feature flags let teams deploy code with a feature switched off and turn it on later, which separates deploying code from releasing a feature.

What Tools Do Teams Use for Continuous Delivery?

Teams building continuous delivery usually combine a CI server with a deployment tool, and many add a feature flag platform.

• CI servers and pipeline runners. GitHub Actions, GitLab CI/CD, and Jenkins run the build and test stages on every change.

• Deployment and release tools. Argo CD deploys to Kubernetes by syncing clusters to what is declared in a Git repository. Octopus Deploy and Harness manage promotion between environments, with approval steps built in.

• Feature flag platforms. LaunchDarkly, Unleash, and Flagsmith let teams switch features on for a subset of users without a new deployment.

What Are the Key Characteristics of Continuous Delivery?

Continuous delivery is defined by a main branch that is always releasable and a release process that never changes shape.

• The main branch is always deployable. A broken build becomes the team's top priority, because until it is fixed nothing can ship.

• Small, frequent changes. Work is merged in pieces small enough to review and test in a day. Large features ship behind flags while still incomplete.

• One path to production. Hotfixes go through the same pipeline as features. An emergency route that skips tests would reintroduce the risk the pipeline exists to remove.

• Measured by delivery metrics. Teams track numbers such as deployment frequency and change lead time, two of the throughput metrics defined by DORA, the software delivery research program run by Google Cloud.

• Fast feedback on every change. The pipeline should tell the author whether a change is releasable before they move on to the next task. Slow pipelines push teams back toward batching changes together.

What Are the Benefits of Continuous Delivery?

The main benefit of continuous delivery is lower release risk, because each release is small and the process behind it is rehearsed daily.

• Faster recovery when something breaks. A fix goes through the same pipeline as any other change, so it can reach production within hours instead of waiting for an emergency release window.

• Less time spent on release work. Manual release checklists and late-night deployment windows shrink or disappear once deploying is routine.

• Easier audits. The pipeline records every release with the commit and the approver attached, which gives compliance teams an audit trail without extra paperwork.

• Higher developer confidence. Engineers who know every change is tested before release make smaller, more frequent commits instead of saving risky work for one big merge.

What Are the Challenges of Continuous Delivery?

The biggest challenge of continuous delivery is that it depends on test automation and infrastructure many teams do not have yet.

• It needs a trustworthy test suite first. Without automated tests the team trusts, a green pipeline means little. Building that suite on a legacy codebase takes months, and the delivery gains arrive only after it exists.

• Database changes are harder to ship in small steps. Code can be rolled back in seconds, but a schema migration that drops a column cannot. Teams use expand-and-contract migrations to keep old and new versions working, which turns one schema change into at least two releases.

• Regulated industries add approval steps. Healthcare and financial software often require documented sign-off before production changes. The pipeline can collect that evidence automatically, but someone still has to design the controls with the compliance team.

• Cultural change costs more than tooling. Teams used to quarterly releases have to break work into smaller pieces and accept that main is always shippable. The tools can be installed in weeks, while the habits take longer.

What Is the Difference Between Continuous Delivery and Continuous Deployment?

Continuous delivery keeps every change ready for production and leaves the release to a person, while continuous deployment removes that final approval.