Continuous integration, delivery, and deployment: what each proves

Use the terms to name the next handoff

The practical difference between continuous integration and continuous delivery is the handoff claim. Continuous integration, or CI, regularly brings changes together in a shared mainline and verifies each integration with an automated build that includes tests. Its useful output is evidence about the integrated source revision. Continuous delivery extends the work to a release candidate that can be deployed when the team chooses. Continuous deployment takes that eligible candidate through an automated production release path. These practices build on one another, but a pipeline should report the specific stage it reached rather than borrowing the most impressive label.

Martin Fowler's updated CI explanation emphasizes frequent integration and automated verification. DORA describes continuous delivery as the ability to release on demand quickly and sustainably. Jez Humble's distinction is that continuous deployment sends qualifying changes to production automatically, while continuous delivery leaves release timing as a deliberate decision. The distinction does not require an unguarded production path. Automated deployment can still enforce tests, reviewed policy, environment rules, and a bounded target. An agent should treat a blocked or rejected gate as a real outcome, not a reason to bypass it so that the system can claim to be continuous.

Delivery and deployment also do not settle whether a feature is exposed to users. A team can deploy code with a feature held behind an existing release control, or release a feature after the underlying binary was deployed earlier. Humble's discussion explicitly separates deployment from release. For an agent handoff, state the artifact and environment action first, then state user-visible behavior only when there is evidence for it. That vocabulary prevents a build job named release from becoming a false production claim.

Sources: Continuous Integration — Martin Fowler · Continuous Delivery vs Continuous Deployment — Jez Humble · Continuous delivery capability — DORA

What CI proves about an integrated revision

Suppose an agent merges a small patch into main. A CI run should identify the exact evaluated revision, the check source, the run attempt, and the test result. If a required check passed on a pull request head but the merge produced a new mainline revision, the handoff should say which revision was actually checked. A green result for the wrong revision is not a substitute for verification of the integrated candidate. The artifact, if one was built, should also be tied to source identity rather than identified only by a friendly filename.

Passing CI is scoped to the checks that ran. It does not prove that every requirement was encoded in those checks, that the build can reach a production provider, or that a running target will behave correctly. If a test was skipped, timed out, or never selected, name that limit instead of calling the run complete. The output to the next agent is therefore narrow: this revision passed these checks from this source at this attempt. The release decision and target evidence remain separate questions.

CI also says little about cadence unless integrations truly happen frequently. A repository can run tests on occasional large branches and still have automated checks, yet miss the fast integration feedback that the practice is intended to provide. The operational concern for an agent is not a ceremonial definition; it is whether the mainline result can be trusted as the candidate for the next stage. If a later commit supersedes it, a green result on the older commit must not be carried forward as proof for the newer one without a documented reuse rule.

Sources: Continuous Integration — Martin Fowler · Continuous delivery capability — DORA

What delivery adds before the release decision

A deliverable candidate needs more than a package sitting in storage. It needs a known source, a reproducible or otherwise traceable artifact, the checks required for that release class, the destination configuration, and a reviewed way to apply it. DORA's deployment-automation guidance describes packages produced by CI, deployment scripts, environment configuration, and a deployment test as inputs to the automated process. A team may also need data compatibility, policy approval, or a rollback candidate. Those needs vary by service; the claim is that the team could make the release decision without inventing a new build or manually reconstructing the path.

Continuous delivery preserves an explicit decision point. That decision may be a human approval, an agent action under delegated policy, a scheduled window, or a business launch choice. The important property is that the candidate remains deployable while waiting. If the environment has drifted, an artifact is missing, or a required check no longer applies, the candidate is not ready merely because it was ready yesterday. The handoff should include the exact digest, target, policy state, and age of evidence so the decision maker can tell whether the release can still proceed.

A ready artifact is not the same as a deployed service. It may never be submitted to a provider. It may be rejected by destination authorization. A provider might accept a request but fail during rollout. The honest delivery verdict is ready to deploy, with the remaining release decision named. If the team says delivered while meaning built, an agent may stop watching before users receive the change. This terminology matters most at the boundary where one agent hands work to another and no one has the full story in working memory.

Sources: Continuous delivery capability — DORA · Deployment automation capability — DORA · Continuous Delivery vs Continuous Deployment — Jez Humble

Three mainline commits through three different claims

In this synthetic history, H1 is CI evidence. H2 illustrates delivery readiness: the package and release path exist, but nobody or no policy has released it. H3 illustrates continuous deployment eligibility because a defined policy automatically submits A3 as P3 after the gates pass. The word automatically describes when the provider request is made, not whether every check is skipped. A required review or environment rule can still stop H3 before submission. If P3 is rejected, stalls, or returns an unknown response, the system should report that state rather than asserting that H3 is live.

Even if P3 reports success, verify the destination serves the intended H3/A3 identity and a critical user journey works. The live target may still have an old revision, a mixed rollout, or a behavioral failure that CI did not catch. The sequence thus yields four separate records: integrated check, releasable candidate, provider delivery operation, and observed live result. A second agent can continue from the last proved record instead of guessing from a green icon or a merge message.

Sources: Continuous Integration — Martin Fowler · Deployment automation capability — DORA · Continuous Delivery vs Continuous Deployment — Jez Humble

Write a handoff that names the stage and its proof

An agent-facing update can be short without being vague. After CI: name the evaluated SHA, check source, conclusion, and artifact digest. After delivery preparation: add target, policy, and the release decision still needed. After deployment submission: add provider operation ID and its current state. After live verification: add the target revision and result of the user path that matters. If any field cannot be observed, say unknown and identify the next read. This avoids both premature success and unnecessary repeated writes.

For Agentic Pipeline, the product contract is a full build-and-ship journey: Auto Profile is the default for a repository without a recipe, testing pushes and shipping eligible merges, while an existing repository-owned recipe remains authoritative. That makes the delivery half part of the intended journey, not an optional badge attached to CI. The agent still needs to read the actual run and delivery evidence for a specific revision; the product promise does not turn a green check into proof that a provider completed or a target is healthy. The shared call to action on this page points interested teams to the current closed-beta path.

When evaluating a pipeline, ask which handoff is missing. If commits are not integrated and checked, improve the CI loop. If CI works but every release needs an improvised build or undocumented environment steps, improve delivery readiness. If the candidate is ready but the release decision should follow a stable policy automatically, design that policy and the deployment operation. If operations run but nobody can identify the live revision, improve verification and monitoring. The names are useful only when they lead to a concrete next action and an honest proof boundary.

Sources: Continuous Integration — Martin Fowler · Continuous delivery capability — DORA · Deployment automation capability — DORA · Agentic Pipeline: Public feature guide