The pipeline: from merge to production without hands

Everything this module has built so far (environments, tests, artifacts) assembles into one machine, and that machine is why modern teams ship daily instead of quarterly.

What is a pipeline?

When Mira’s PR merges, a pipelineConcept · lights on your mappipelineThe scripted conveyor that takes merged code through building, testing, and deploying with no hands on it. Written down as a file inside the repository itself; each step must pass before the next begins, so a failure anywhere halts the change short of customers. wakes up: an automated sequence that carries her change from merge toward production, running the same scripted gauntlet every time, for every change, with no human hands.

A typical ride: build the artifact, run the test pyramid, deploy to staging, run the smoke tests, promote to production. Every stage is a gate, and failing one stops the ride there.

What is the build?

The pipeline’s first act is the buildConcept · lights on your mapbuild (artifact)The pipeline’s opening move: compiling and bundling the source and baking it into the container image every later stage will use. When engineers report a broken build, this stage failed and the line is stopped; build artifacts are its output (Module 8’s word, in overalls).: turning source code into the runnable artifact.

For the coffee app, that artifact is Module 8’s container image, compiled, bundled, and baked once. The four-worlds lesson promised one artifact, promoted through every environment, and the build step is the machinery that keeps that promise.

Two phrases you will hear constantly: “the build is broken” means this step failed and nothing can ship until it is fixed; “build artifacts” are what the step produces.

Three practices, each bolder than the last

On top of the pipeline sit three named practices, each handing the machinery a bigger decision than the last.

What is continuous integration?

Continuous integrationConcept · lights on your mapcontinuous integrationCI: keep everyone’s work flowing into main in small, frequent merges, and have machines build and test each one automatically. Red CI means a check failed on main, and unbreaking it outranks whatever else was planned. (CI) is the practice of merging small changes into the shared main branch frequently, and letting bots build and test every single merge.

Module 11 showed why. A branch that lives for a month drifts so far from main that merging it back is agony, and CI solves that problem with policy plus automation. Nobody’s work sits unmerged long enough to go bad.

When a merge fails the bots’ checks, engineers say “CI is red.” Fixing red CI takes precedence over new work because a broken main blocks everyone.

What is continuous delivery?

Continuous deliveryConcept · lights on your mapcontinuous deliveryCD, the cautious version: the pipeline takes each change all the way to ready-to-ship and stops, leaving a person to choose the moment. What it guarantees is that shipping is always safe; what it leaves to humans is when. goes further. Every change that survives the pipeline is packaged and proven deployable. Production-readiness becomes the codebase’s default state.

A human still chooses the moment; someone presses the deploy button. But the pipeline guarantees the button is always safe to press. At any hour, a tested release is loaded and waiting.

What is continuous deployment?

Continuous deploymentConcept · lights on your mapcontinuous deploymentCD, the bold version: nothing waits for a person. Clear the automated gates and the change is in customers’ hands within the hour, potentially many times a day. Only works when the tests are trusted completely, which is why the best-run engineering organizations invest so heavily in them. removes even the button. Every change that passes every automated gate deploys to production automatically. Merged at 10:14, live by 10:40, possibly dozens of times a day.

This requires deep trust in the test pyramid because the bots are the only gate left, and it is the working practice at many of the industry’s most admired engineering organizations.

What does CI/CD mean?

CI/CDConcept · lights on your mapCI/CDThe catch-all label for automated building, testing, and shipping taken together. Hearing that something is in CI/CD means it has been handed to the machinery. This is what made releasing software an everyday act instead of a quarterly ceremony. is the umbrella acronym for the whole automated build-test-deploy apparatus. “It’s in the CI/CD pipeline” means the bots are on it.

One ambiguity is worth naming honestly. Both continuous delivery and continuous deployment abbreviate to CD, and people rarely say which they mean. The practical difference is a single question: does a human still press the deploy button?

The pipeline is code, too

Where does the pipeline itself live? It lives in the repository, as a text file. That is Module 8’s infrastructure-as-code instinct, striking again.

The example you are likeliest to meet is GitHub Actions: pipeline stages defined in a file that is versioned, reviewed, and changed through PRs like everything else. Simplified, one reads almost as plain English:

Now watch it run. Here is Mira’s merge, riding the whole machine:

Why more deploys mean less risk

The pipeline’s obvious gift is speed. Its deeper gift is changing the economics of mistakes.

A quarterly release bundles three months of work. When something breaks, which of nine hundred changes did it? The suspect list is the whole quarter.

A daily (or hourly) deploy ships a tiny diff. When something breaks, the suspect list has one name, and the next lessons’ tools make turning it off or rolling it back surgical.

Small batches and fast feedback are Module 11’s agile bet, now enforced by bots.

The mental model to remember

The pipeline is the automated gauntlet every merge rides toward production. The build is its first act. Source code becomes the runnable artifact.

Continuous integration: merge small and often, and bots build and test every merge. Continuous delivery: every surviving change is proven deployable, and a human picks the moment. Continuous deployment: no button, passing the gates is reaching production.

CI/CD is the umbrella for all of it, machinery defined in a file in the repo, like any other code.

You should now be able to hear “the build is broken,” “CI is red,” or “it deploys automatically on merge” and know exactly which part of the machine is being discussed, and explain why small, frequent, bot-gated deploys are safer than big quarterly ones.