CI/CD Course
Continuous Delivery
In this lesson
Continuous Delivery (CD) is the practice of keeping software in a state where it can be released to production at any moment — not just in theory, but in fact. Every change that passes CI is automatically built into a versioned artifact, deployed to a staging environment, and validated with end-to-end tests. A human then makes the final decision to release to production, but that decision requires no technical preparation. The code is already there, already tested, already packaged. Releasing becomes a business decision, not an engineering event.
CD sits directly on top of CI. Where Lesson 4 explained how code is continuously verified, this lesson explains how that verified code is continuously prepared for release. The distinction between Continuous Delivery and Continuous Deployment — which is often confused — is also covered in full here, because it is one of the most frequently misunderstood concepts in this entire course.
What "Always Deployable" Actually Means
The phrase "always deployable" sounds simple but has a precise technical meaning. It does not mean "the code compiles." It means that at any point in time, a stakeholder could ask an engineer to release the current state of the main branch to production, and that engineer could do so — safely, confidently, and within minutes — without needing to run manual checks, coordinate with other teams, or hope that nothing has drifted since the last release.
Achieving this state requires that the delivery pipeline be running continuously in the background. Every merge to main triggers not just the CI checks from Lesson 4, but a second, longer pipeline that promotes the verified build through a sequence of environments — typically staging, sometimes pre-production — running progressively deeper tests at each stage. By the time a build reaches the end of the pipeline, it has been subjected to every automated check the team has defined. The only thing left is the human decision.
The Loaded and Ready Analogy
Think of a commercial aircraft sitting at the gate. Before any passenger boards, the plane has been fuelled, inspected, loaded, and cleared by air traffic control. The captain does not start these processes when they decide to fly — everything is already done. The captain's decision to push back from the gate is purely about timing and business conditions, not technical readiness. Continuous Delivery puts software in the same state: the release is loaded and ready. The business decides when to push back.
The Delivery Pipeline: From Commit to Ready
The delivery pipeline extends the CI pipeline. Where CI focuses on fast verification of a single change, the delivery pipeline focuses on proving that the change is safe to ship in a production-like context. The stages grow progressively slower and more thorough as the build moves toward production.
The Delivery Pipeline — Stage by Stage
The Approval Gate: A Business Decision, Not a Technical One
The approval gate is the defining characteristic of Continuous Delivery. It is what separates CD from Continuous Deployment. But understanding what the approval gate is for — and what it is not for — is critical.
The approval gate exists to answer business questions: Is this the right time to release this feature? Has the marketing campaign launched? Is the support team briefed? Are we within the release window allowed by our SLA? These are legitimate reasons to pause before releasing.
The approval gate does not exist to answer technical questions. If a reviewer is asking "but is it actually safe to release?" then the pipeline has failed — the automated stages should have answered that question already. An approval gate that acts as a manual technical review is a symptom of insufficient automated testing, not a feature of good CD practice.
Good vs Bad Reasons to Hold at the Approval Gate
Continuous Delivery vs Continuous Deployment
These two terms share an abbreviation (CD) and are frequently conflated, but they describe meaningfully different practices. The difference is a single gate: in Continuous Delivery, a human approves the final production release. In Continuous Deployment, that gate does not exist — every change that passes all automated checks is deployed to production automatically, with no human in the loop.
Neither is universally better. Continuous Deployment is the right choice for teams with high test confidence, mature monitoring, and a culture of small safe changes — typically SaaS products where fast iteration is a competitive advantage. Continuous Delivery is the right choice for organisations that have legitimate reasons to control release timing — regulated industries, enterprise software, products with coordinated launch requirements. Lesson 6 covers Continuous Deployment in dedicated depth.
A Continuous Delivery Release — Start to Production
v2.14.1. Automatically deployed to staging.v2.14.1 is live in production. The same image that was tested on staging — nothing rebuilt, nothing re-packaged, nothing different.Warning: Never Rebuild the Artifact for Production
The artifact built during CI must be the same artifact deployed to production — promoted unchanged through staging, pre-production, and finally production. Teams that rebuild the artifact from source at each environment introduce a silent risk: the build environment may differ slightly, producing a different binary. The whole point of artifact promotion is that what you tested is exactly what you ship. Rebuilding breaks this guarantee entirely.
Key Takeaways from This Lesson
Teacher's Note
Ask your team: "If the CEO asked us to release right now, how long would it take and what would we need to do?" The answer tells you exactly how far you are from genuine Continuous Delivery.
Practice Questions
Answer in your own words — then check against the expected answer.
1. What is the name for the single manual step in a Continuous Delivery pipeline — the point where a human reviews the automated results and decides whether to promote the build to production?
2. In a Continuous Delivery pipeline, what is the versioned, immutable package — such as a Docker image or a JAR file — that is built once and promoted unchanged through staging and into production?
3. What is the name for the environment that mirrors production and is used to run acceptance tests automatically before a build is presented for human approval?
Lesson Quiz
1. A team's pipeline automatically builds, tests, and deploys every merge to staging. A product manager then reviews the result and clicks a button to release to production. Which practice is this?
2. A release manager is holding a build at the approval gate because they want to manually test the feature before it goes live. What does this indicate about the team's pipeline?
3. A team rebuilds their application from source code each time it is deployed to a new environment — first to staging, then to production. What risk does this introduce?
Up Next · Lesson 6
Continuous Deployment
Remove the approval gate entirely — learn how teams like Amazon and Netflix ship to production hundreds of times a day with zero human intervention, and what it takes to do it safely.