What is the difference between CI, continuous delivery and deployment?

What is the difference between CI, continuous delivery and deployment?

Continuous integration (CI), continuous delivery, and continuous deployment are three practices that each automate more of the path from a code change to production. CI builds and tests each merged change. Continuous delivery keeps each passing build ready to release when a person approves it. Continuous deployment releases each passing build with no approval at release.

Continuous delivery and continuous deployment share the abbreviation CD, so the CD in CI/CD can mean either one. They run the same pipeline and differ only at its last step.

Martin Fowler defines continuous integration as each member of a team merging their work with everyone else's at least daily, with an automated build and tests on each merge. CI ends when a change is tested on the main branch, before it reaches users.

What is continuous delivery?

Continuous delivery is a practice that keeps each change that passes the pipeline ready to release, so a person can put it into production at any time with one decision. Fowler's test for continuous delivery is that a business sponsor could ask to deploy the current development version to production at a moment's notice and nobody would be surprised.

A continuous delivery pipeline carries each merged change through these steps:

1. The CI stage builds the change and runs the fast tests.
2. The pipeline packages the build once and stores that package.
3. The pipeline deploys the package to a staging environment and runs smoke tests and slower tests there.
4. The package waits until a person approves the release.
5. The pipeline deploys the same package to production with the same script.

The approval is a manual quality gate and a human-in-the-loop step. The team names who can approve, often someone who owns the release timing, e.g. a product owner. Some approvers also try the build in staging before they approve it.

Continuous delivery does not require frequent releases. Jez Humble describes its goal as deployments that are "predictable, routine affairs that can be performed on demand." The business chooses the pace.

What is continuous deployment?

Continuous deployment is a practice that releases each change that passes the automated pipeline to production, with no manual approval between the merge and the release. It runs the delivery pipeline without step 4. Fowler writes that to do continuous deployment, a team must be doing continuous delivery.

Without an approver, the automated checks are the last check before customers. The definition of continuous deployment names none of these safeguards, but teams that use it often add them:

• Feature flags. A feature flag is a setting that keeps code switched off for customers. A change can then deploy to production before the team releases it to users.
• Small, reversible releases. A canary release goes to a small share of users first, and the team rolls it back if errors rise.
• Checks in production. Monitoring and scheduled checks that run the main workflows find failures after release, which is testing in production.

When should a team use delivery or deployment?

Continuous delivery fits a team when one of these is true:

• A release needs a recorded approval. Some auditors expect an approval at release to meet segregation of duties, a common regulatory rule that requires someone other than the author to approve each change.
• Releases follow a schedule. A mobile app waits for app store review, and a launch can wait for a planned date.
• The tests miss what people check by hand. The approver tries a workflow that no test covers, as in the example below.

Continuous deployment fits when the checks cover the main workflows, a bad release can be switched off or rolled back quickly, and monitoring shows errors soon after release. In return, each release holds few changes, so a failure is easier to trace and roll back. Segregation of duties does not rule it out when auditors accept a required review before the merge. Deployment frequency and change failure rate, two of the DORA metrics, show whether a faster pace raises the share of deployments that fail.

Here is an illustrative example. Acme Co. sells furniture online, and its web store uses continuous delivery. One change shows what the approval step adds:

1. A developer at Acme asks a coding agent to "Let customers edit their delivery address during checkout."
2. The agent's change passes CI, including 3 tests the agent wrote, and a reviewer merges it.
3. The pipeline deploys the build to staging, and the smoke test loads the home page and passes.
4. Before approving the release, the product owner tries checkout in staging with 2 items in the cart. The address saved, but the cart emptied.
5. The product owner holds the release, and the developer has the agent fix the code.
6. The team adds a browser test that changes the address and checks that the cart still holds 2 items.

Under continuous deployment, the bug would have reached customers after step 3. This example is simplified. A real team would also watch production errors after each release.

What changes when a coding agent writes the code?

A coding agent raises the number of changes that reach the pipeline, and it often writes the tests for its own code. When the agent's code misses part of a request, its tests often miss the same part. Unless another test in the suite covers that part, continuous deployment then releases the change to customers.

An agent can also break working features that its task never touched. The agent's own tests usually cover only its task, so the team's regression testing is the check that can stop such a change before release.

Under continuous delivery, an approver who sees many green builds a day can stop trying them. The approval then adds wait time but no check.

A practical adjustment is to keep a person's approval on agent-written changes until the automated checks cover the main workflows. Running each change in an ephemeral environment lets a person or a test try it before it merges. Fast checks inside the agent's loop, which is shift-left testing, stop some broken changes earlier.

Can a team use all three together?

A team that uses continuous deployment uses all three, because each practice contains the one before it. A team can also mix the two CD practices by component, e.g. continuous deployment for a web app and continuous delivery for its mobile app.

Layering the three does not remove these limits:

• A green pipeline shows only that its checks passed. None of the three practices shows that a change does what was asked. At Acme, the build with the cart bug passed CI and the smoke test in staging.
• Staging is not production. Some failures appear only under real traffic and real data, after the release.
• Some releases are hard to undo. A rollback restores the old code but not data that the release changed, e.g. rows a database migration rewrote.

How do continuous integration, delivery, and deployment compare?

The three practices differ on these attributes:

FAQs

What does CD stand for in CI/CD?

CD in CI/CD stands for continuous delivery or continuous deployment, and teams use the abbreviation for both. The two differ at the release step. Continuous delivery waits for a person to approve each release, while continuous deployment releases each passing change with no approval at release.

Does continuous deployment need feature flags?

Continuous deployment does not require feature flags, but teams that release each passing change often use them. A feature flag keeps code switched off for customers, so a change can reach production and stay unseen until the team turns the flag on.

Can a regulated team use continuous deployment?

A regulated team can use continuous deployment when its rules accept an approval before the merge instead of before the release. A required review by someone other than the author can meet a segregation of duties rule. A team whose rules need a recorded approval at release uses continuous delivery.

Who approves a release in continuous delivery?

A release in continuous delivery is approved by a person the team names, often someone who owns the release timing, e.g. a product owner. The pipeline has already built and tested the change, so the approval decides when to release. Some approvers also try the change in staging before they approve it.