CI/CD / Integration and candidate foundations / Lesson 1

Integration, delivery, and deployment are different promises

Define what a green pipeline proves and where release decisions still remain.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish continuous integration, continuous delivery, and continuous deployment.
Write a bounded release contract for a synthetic application.

Integration checks a shared change

Continuous integration means integrating small changes into a shared development line frequently and checking the combined result. A nightly build of isolated long-lived branches leaves integration risk unresolved even when every branch is green. Imagine Parcel, a synthetic address-label application: one change alters a formatter while another changes its caller. Tests on each isolated branch can pass while their combination fails. CI should give timely evidence about the revision that will actually be integrated, with failures visible to the people who can correct them.

Delivery preserves a releasable candidate

Continuous delivery extends that feedback into a repeatable path that can produce a release candidate on demand. Production release may still need a business decision or an explicit approval. Continuous deployment additionally sends qualifying changes to production automatically. These are operating practices, not features guaranteed by naming a file pipeline.yaml. A pipeline that compiles successfully but requires undocumented manual packaging has not established a reliable delivery path. Identify every remaining manual input and decide whether it is a legitimate decision or an avoidable source of variance.

text A conceptual delivery chain

source revision -> build -> tests -> release candidate
release candidate -> approval -> environment adoption

The arrows describe evidence dependencies. Approval changes authorization, not the candidate bytes. This is a teaching diagram and does not configure a runner or deploy anything.

Give green a precise meaning

For Parcel, define green as a source revision that passed formatter tests, produced a package, and retained its manifest. This does not prove that a database migration is compatible, an external carrier is available, or every customer journey works. A useful contract states included checks, known exclusions, the artifact identity, and who owns the next decision. Without this boundary, teams use the same green icon to mean compilation, release readiness, or healthy production, then discover the disagreement during an incident.

Model readiness without touching infrastructure

The following complete local model represents three required observations. It treats a missing result as failure rather than silently accepting it. Real delivery systems need richer states such as canceled, skipped, expired, and approved, but a small model makes the central rule visible: every required observation must refer to the intended candidate. A successful check from yesterday cannot satisfy today’s revision merely because its job name matches. Carry revision identity with evidence before combining results.

python A deliberately incomplete readiness record

required = {"build", "unit", "manifest"}
observed = {"build": True, "unit": True}
missing = sorted(required - observed.keys())
print("ready" if not missing and all(observed.values()) else "blocked")
print(missing)

Expected output

blocked
['manifest']

The manifest observation is absent, so readiness is blocked. This program only evaluates in-memory synthetic data; it is not a CI status query.

Make failures actionable

A delivery process needs owners for source, build infrastructure, packaging, release authorization, and runtime verification. One person may hold several roles in a small team, but responsibilities still differ. When unit tests fail, a release approver should not compensate by pressing a manual button. When the runner is unavailable, changing application logic is equally misplaced. Record the first failed contract, retain enough non-sensitive evidence to reproduce it, and send it to the responsible owner. Short feedback loops depend on clear action, not merely frequent automation.

Common errors and fixes

A green build is described as healthy production.

Why it happens: Compilation evidence was stretched beyond the scope of the job.
How to fix it: State precisely which checks passed and verify runtime behavior separately.
Prevent it next time: Publish the meaning and exclusions of each required status.

Manual packaging changes the approved candidate.

Why it happens: The release path rebuilds or edits bytes after testing.
How to fix it: Package once and promote an identified candidate through the decision boundary.
Prevent it next time: Record package identity with test and approval evidence.

A scheduled branch build is treated as continuous integration.

Why it happens: Work remains separated until a large late merge.
How to fix it: Integrate smaller changes and test the combined revision frequently.
Prevent it next time: Track integration delay and keep branches short enough for the team’s review capacity.

Check your understanding

1. Parcel has automatic tests and a manual production approval. Is that continuous deployment?

Show worked solution

It can implement continuous delivery if each qualifying revision reliably produces a releasable candidate. The manual production decision means production adoption is not automatically continuous deployment. Inspect whether packaging and verification are repeatable before making either maturity claim.

2. The formatter check passed for revision A, while packaging passed for revision B. Can their statuses be combined?