Skip to content

continuous delivery

Continuous delivery, or CD, is a software development practice that keeps every change in a deployable state once it passes the automated build-and-test pipeline. The team can then release to production on demand, triggering a deploy whenever it wants instead of treating a release as a rare event.

Continuous delivery extends continuous integration by carrying each integrated change all the way to a release-ready artifact. It stops one step short of production, at a manual gate where a human decides when to push the button:

A left to right pipeline (Commit, Build and test, Staging deploy) into a teal Release-ready artifact box, then a yellow Manual gate diamond branching by two arrows to a green Production box.
The manual gate is the seam, a human approves the production deploy unless auto_deploy flips it on.

The pipeline does everything except that final deploy, so a typical run ends parked and waiting:

Language: Shell 
$ ci run --pipeline release
build        packaged app-2.7.0
test         412 passed
staging      deployed, smoke tests green
production   waiting for approval

The artifact named in that output is releasable right now, and continuous delivery is the discipline of keeping it that way after every single commit.

How It Shows Up in Practice

A Python developer meets continuous delivery as the shape of the team’s pipeline rather than as a tool with that name. GitHub Actions, GitLab CI/CD, and Jenkins all express it the same way, as a sequence of stages that build the package, run the test suite, deploy to a staging environment, and then gate the production deploy behind a manual approval step.

The payoff is that releasing stops being a project of its own. Because the pipeline rebuilds and revalidates on every merge, the latest green commit is always shippable, so a release turns into one click rather than a week of integration and hand testing. Teams earn that confidence with a smoke test against staging, then watch the production rollout through their observability stack.

The defining trait is that manual gate at the end.

Once a human approves, the deploy itself still rides on a release strategy such as a blue-green deployment or a rolling deployment.

Continuous Delivery vs. Continuous Deployment

The two terms share an acronym and differ by one decision. Continuous delivery keeps every change ready to ship and leaves the production deploy as a human choice, often to line a release up with a launch, a definition of done sign-off, or a quiet traffic window.

Continuous deployment removes that final gate, so any change that clears the pipeline goes live with nobody pressing a button.

Teams reach for continuous delivery when they trust their automation but still want a person to own the timing of a release. They graduate to continuous deployment once the pipeline and monitoring are trusted enough to take that person out of the loop. To see what changes when the gate comes out, read continuous deployment.

Continuous Integration and Deployment for Python With GitHub Actions

Tutorial

Continuous Integration and Deployment for Python With GitHub Actions

With most software following agile methodologies, it's essential to have robust DevOps systems in place to manage, maintain, and automate common tasks with a continually changing codebase. By using GitHub Actions, you can automate your workflows efficiently, especially for Python projects.

advanced devops

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback