Module 1: Why Cicd And Gitops

3. CI, CD, and CD: three things, one acronym

Description

"CI/CD" is, probably, the most-used and least precisely defined term in all of modern infrastructure. Almost everyone says it in one breath, as if it were a single idea. It isn't: they're three distinct concepts, two of which literally share the same acronym ("CD") with different meanings. This lesson gives you the three exact definitions, with no ambiguity, and shows you where each piece of the guide you're about to build lands.

Connection to the module

This lesson is purely conceptual, and it's the most important one in the entire module for what comes after: every workflow you're going to write from Module 2 onward is, specifically, CI or specifically CD —and you're going to be able to name it precisely, not just call it "part of the pipeline." Lesson 4 builds on this one, adding GitOps as the principle that makes it possible to automate the CD part without losing control.

Analogy: the assembly line

Imagine a factory with an assembly line. Every part that comes in passes through a series of automatic stations: one checks dimensions, another checks for visible defects, another tests that the part fits with the others. No person inspects every individual part by hand —that would be too slow for the volume the factory handles— but the line does stop itself if a part fails any of those stations. That, exactly that, is continuous integration: every change goes through the same automatic checks, and the change doesn't move forward if something fails.

Now, at the end of that line, there are two possible factories. In the first, the parts that passed all the checks get stacked in a warehouse, ready to ship — but a person has to sign off on the shipping order before the truck leaves. That's continuous delivery: always ready, with an explicit human gate before anything goes out the door. In the second factory, the parts that pass all the checks go straight onto the delivery truck, with nobody signing anything — the very fact of having passed the line is the authorization. That's continuous deployment: it deploys on its own, with no human intervention in the last step.

The three definitions, with no ambiguity

CI — Continuous Integration

What it answers: does this change break anything?

What it does: every time someone proposes a change —typically, every push to a branch or every pull request update— an automatic process runs validations: formatting, syntax, tests, and —in this guide's specific case— terraform plan. CI's result is a yes/no signal: the change passed the checks, or it didn't.

Who decides to run it: nobody — it runs on its own, automatically, on every change. There's no button to press to make CI execute.

In this guide: all of Module 3 builds half of Andes Cargo's pipeline's CI: terraform fmt -check, terraform validate, and terraform plan, run automatically on every Pull Request, with the plan as the artifact a human is going to read before approving the merge.

CD — Continuous Delivery

What it answers: is this change ready to deploy, and who says yes?

What it does: once CI confirms the change doesn't break anything, the system guarantees that change could deploy at any moment —it's built, tested, packaged, ready— but actually deploying it requires an explicit human action: approving an Environment, pressing a button, merging a PR to a protected branch. Automation stops right before the line a human has to cross on purpose.

Who decides to run it: a human, at the exact moment they choose, with an explicit, recorded gesture.

In this guide: the Environments pattern with required reviewers from Module 4 (lesson 6) is, specifically, continuous delivery — the change is ready, but a person has to approve it before apply runs against that environment. It's described with the real click-path; under act, that specific protection can't be demonstrated live (exact technical reason in that lesson), but the mechanism is exactly this one.

CD — Continuous Deployment

What it answers: is this change already in production?

What it does: exactly the same as continuous delivery, with one decisive difference: there's no human gate at the last step. Every change that passes CI deploys automatically, with nobody manually approving that specific deployment.

Who decides to run it: nobody, at the moment of deployment — the decision was already made ahead of time, by designing the pipeline this way. (There almost always was a human decision at an earlier point: merging the PR to main. That matters, and this guide is explicit about it — see the next section.)

In this guide: apply.yml, built in Module 5, triggers terraform apply automatically on every push to main, with no additional button to press after the merge. It's, technically, continuous deployment of infrastructure.

The table that resolves the confusion once and for all

	CI	CD (delivery)	CD (deployment)
Full name	Continuous integration	Continuous delivery	Continuous deployment
Answers	Does it break anything?	Is it ready, and who says yes?	Is it already live?
Runs on	Every `push`/PR	After CI, always ready	After CI, without waiting
Human gate at the end	Not applicable (it's the validation itself)	Yes, explicit	No
In this guide	`ci.yml` — Module 3	Environments with approval — Module 4	`apply.yml` — Module 5

The mistake almost everyone makes: saying "we do CD" without specifying which of the two. A team that says "we have continuous delivery" and another that says "we have continuous deployment" could be describing radically different processes —one with a human button at the end, the other with none— and the acronym, alone, doesn't distinguish them. From this lesson onward, this guide never uses "CD" without clarifying which one.

Where, exactly, the pipeline you're about to build lands

sequenceDiagram
    participant Dev as Developer
    participant PR as Pull Request
    participant CI as ci.yml (CI)
    participant Main as main branch
    participant CD as apply.yml (CD-deployment)

    Dev->>PR: git push to feature/add-shipment-tags
    PR->>CI: triggers automatically
    CI->>CI: fmt + validate + plan
    CI-->>PR: plan published as evidence
    Note over PR: A human reads the plan and approves the PR (CD-delivery, here)
    PR->>Main: merge
    Main->>CD: triggers automatically (push to main)
    CD->>CD: terraform apply
    Note over CD: No additional button — continuous deployment, from this point on

Notice something important, which you're going to see again in Module 6's lesson 5: this guide's human review doesn't disappear when it reaches apply.yml — it lives in the earlier step, the Pull Request approval. That is, with technical precision, what makes Andes Cargo's pipeline safe without depending on an additional button after the merge: the human gate exists, it's just located at reviewing the plan, not at a second click after merging. Module 4 (lesson 6) optionally adds a second gate —an Environment with approval— for the case where an organization wants explicit review at that point too, turning that specific part of the flow into continuous delivery instead of pure continuous deployment.

Common mistakes

Using "CD" without specifying which one, and not noticing (by far the most common one). What happens: someone says "we're going to do CD for this project" without clarifying whether the pipeline stops at a human gate or deploys on its own. Why it happens: in everyday use, almost nobody distinguishes the two —the acronym is identical, and context rarely forces clarification. How to spot it: if, in a conversation about CI/CD, you can't answer with certainty "is there a human button before this reaches production, or not?" How to fix it: always use the full name the first time you mention it in a technical conversation ("continuous delivery" or "continuous deployment"), exactly as this guide does from this lesson onward.

Thinking CI ends when the code "compiles" (scope-based, in this guide's context). What happens: someone assumes that, since there's no application code in andes-cargo-infra/ (it's HCL, not Python or Java), the concept of CI doesn't apply. Why it happens: CI is almost always associated with traditional software testing. How to spot it: if you think this guide's Module 3 "isn't real CI" because it validates HCL instead of application code. How to fix it: CI is a concept agnostic to what's being validated — it's the practice of running automatic checks on every change, before merging. terraform fmt -check, terraform validate, and terraform plan fulfill exactly that function for infrastructure, the same way a test suite fulfills it for an application.

Believing "continuous deployment" means "no human review whatsoever" (conceptual, corrected above). What happens: someone concludes that, since apply.yml doesn't have a button after the merge, nobody reviewed the change before it got applied. Why it happens: it's easy to lose sight of the fact that the human gate can live at an earlier point in the flow. How to spot it: if your summary of this guide's pipeline is "nobody reviews anything, everything's automatic." How to fix it: the review exists — it lives in the Pull Request approval, over the exact plan that later gets applied (Module 5, needs + artifacts guarantee it's the same one). Continuous deployment describes where the gate lives (before merging, not after), not that the gate disappeared.

Exercises

Exercise 1 — Classify three real scenarios. For each one, decide whether it describes CI, CD-delivery, or CD-deployment: (a) a team runs automatic tests on every Pull Request, and nobody can merge if they fail; (b) a team has a button in their internal tool that a product manager presses to ship the new version to users; (c) a team merges to main and, thirty seconds later, the new version is already serving real traffic, with nobody having approved it separately.

See solution

(a) CI — validation runs on every change, and it blocks the merge if it fails; there's no notion of "deploying" yet, only of "this change is valid." (b) CD-delivery — the system left everything ready, but a human (the product manager) has to explicitly press the button for it to go to production; that button is the gate. (c) CD-deployment — there's no human gate after the merge; the merge itself is, in effect, the deployment authorization.

Exercise 2 — Locate this guide's pipeline's human gate. Without looking at this lesson's diagram, explain in two or three sentences exactly where the human review lives in the Andes Cargo pipeline you're about to build, and why that lets apply.yml run without an additional button, safely.

See solution

The human review lives in the Pull Request approval: before merging to main, a person reads the plan that ci.yml published (Module 3) and decides whether to approve that specific change. Since apply.yml (Module 5) is designed to apply exactly that same plan —not one recalculated after the merge— the fact that there's no additional button after the merge doesn't mean nobody reviewed anything: it means the review point is the merge itself, not a later step. This is what lets you call this part of the flow "continuous deployment" without sacrificing human control over what gets applied.

Exercise 3 — Design the reverse pipeline. Imagine Andes Cargo decides it wants to add a second human gate, specifically before apply.yml runs against the production environment (not just at PR approval). What GitHub Actions mechanism, already named in this guide though not yet built, would solve exactly that? Which classification (CI, CD-delivery, CD-deployment) would that specific part of the flow fall into after the change?

See solution

The mechanism is an Environment with required reviewers, previewed in this lesson and built in detail in Module 4 (lesson 6): you configure apply.yml so the job that runs terraform apply is associated with an Environment named, for example, prod, and that Environment is configured so one or more specific reviewers must approve before the job continues. With that change, the "apply against production" part stops being pure continuous deployment and becomes continuous delivery: the change is still always ready as soon as it's merged, but now there's a second, explicit human gate, separate from the PR approval, before the real apply happens.

Summary and next step

In this lesson you precisely defined the three things sharing the acronym "CI/CD": continuous integration (validating every change, with no human gate because it's the validation itself), continuous delivery (always ready, with an explicit human gate before deployment), and continuous deployment (it deploys on its own, with no additional button). You saw where each piece of the pipeline you're about to build in this guide lands: ci.yml is CI (Module 3), Environments with approval are continuous delivery (Module 4), and apply.yml triggered by push to main is continuous deployment of infrastructure (Module 5) —with the real human gate living in the Pull Request approval, not absent.

Before moving on you should be able to: name the three definitions without confusing them; explain why "CD" without clarifying which one is a common source of misunderstandings; and locate, unaided, which module of this guide builds each of the three pieces.

Lesson 4 adds the missing piece that makes all of this work without a human having to manually run every step: GitOps — the principle that Git, not anyone's memory, is the single source of truth for what infrastructure should exist.

Resources

GitHub Docs — About continuous integration — GitHub's official definition of CI, the basis for this lesson.
Martin Fowler — Continuous Delivery — one of the industry's most-cited sources on the exact distinction between continuous delivery and continuous deployment.
AWS — What is CI/CD? — AWS's official explanation, with the same three-piece vocabulary used in this lesson.
src/paths/aws-cloud-ecosystem/VALIDACION.md (NIEVA) — the market evidence confirming CI/CD as the ecosystem's most-cited gap, this guide's motivation.

← Previous2. The trouble with manual `apply`Next →4. What is GitOps