CI/CD Pipelines
Every push tested, every merge deployable — automation as the safety net.
40 minDifficulty 3/5ops · automationAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
Why this exists
A developer merges a change, manually runs the test suite locally (or skips it because "it's a small change"), and manually deploys by SSHing into a server and pulling the latest code. Every one of these manual steps is a place a mistake can happen — a forgotten test run, a deploy to the wrong server, a step done out of order. CI/CD replaces every one of these manual, error-prone steps with an automated, identical pipeline that runs the same way every single time.
The mental model
Continuous Integration (CI) means every code change is automatically built and tested the moment it's pushed — catching problems within minutes, while the change is still fresh in the author's mind, rather than days later. Continuous Deployment (CD) means a change that passes CI is automatically deployed, with no manual 'click the deploy button' step — the two together form a pipeline where merging code and it reaching production are connected by an automated, repeatable process rather than a human doing each step by hand.
How it works
A pipeline is a sequence of automated stages, each gating the next
A typical pipeline runs, in order: install dependencies, lint, run tests, build, and (if all prior stages pass) deploy — each stage acts as a GATE, and a failure at any stage stops the pipeline before the next stage runs. This is deliberate: there's no value in deploying code that failed its tests, so the pipeline structurally prevents that from happening.
Fast feedback is the entire point — a slow pipeline defeats its own purpose
If CI takes 45 minutes to report a failure, a developer has already moved on to something else by the time they find out their change broke something — context-switching back is expensive. A pipeline that reports failures within a few minutes lets a developer fix the issue while it's still fresh, which is a large part of why teams invest in parallelizing tests and caching dependencies to keep pipeline duration low.
Continuous DELIVERY vs continuous DEPLOYMENT is a meaningful, deliberate distinction
Continuous DELIVERY means every passing change is automatically prepared and READY to deploy, with a human clicking a button for the final step — a deliberate checkpoint. Continuous DEPLOYMENT goes one step further and deploys automatically with NO human gate at all. Many teams choose delivery over full deployment specifically to retain a manual decision point before customer-facing changes go live, even with everything else automated.
A pipeline running IDENTICALLY for every change is what makes it trustworthy
The value of CI/CD isn't automation for its own sake — it's that the SAME sequence of checks runs, in the SAME order, with the SAME environment, for every single change, with zero variance from human inconsistency (someone forgetting a step, running tests on a different machine with different dependencies). This consistency is what actually catches problems reliably, not any individual step in isolation.
The mechanism
A code push or pull request triggers the pipeline automatically. Each stage runs in a clean, consistent environment, and a failure at any point halts the pipeline immediately, notifying the author with specifics about what failed. Only if every stage succeeds does the pipeline proceed to build an artifact and, under continuous deployment, automatically deploy it — with no manual intervention required at any point in a fully successful run.
flowchart LR P[Push / PR] --> I[Install deps] I --> L[Lint] L --> T[Test] T --> B[Build] B -->|CD: automatic| D[Deploy] T -.->|any stage fails| F[Pipeline stops, author notified]
What people get wrong
- CI/CD means every change automatically goes straight to production, with no safety net.
- A well-designed pipeline includes multiple gates — tests, staging deployment, sometimes manual approval — before production; 'automated' describes the PROCESS being consistent and hands-off, not the absence of safety checks along the way. This misconception makes teams hesitant to adopt CI/CD out of fear of losing control, when in practice the pipeline typically enforces MORE rigor and consistency than manual deployment did, not less.
- Once CI/CD is set up, the pipeline itself doesn't need ongoing attention.
- A pipeline that grows slow (untuned test parallelization, no caching) or flaky (intermittently failing for reasons unrelated to real bugs) actively erodes trust and gets worked around — pipelines need the same ongoing care as any other piece of infrastructure. A slow or flaky pipeline that developers learn to distrust or route around defeats its entire purpose, and this degradation happens gradually enough that it's easy to under-invest in maintaining pipeline health.
- Continuous delivery and continuous deployment are the same thing, or the distinction doesn't matter in practice.
- The distinction is exactly whether a human clicks a button for the final production deploy — delivery keeps that manual gate, deployment removes it entirely — and choosing between them is a genuine, deliberate decision about risk tolerance, not an interchangeable detail. Conflating the two obscures a real organizational choice: whether the team wants a deliberate human checkpoint before customer-facing changes go live, which many regulated or risk-sensitive teams specifically want to keep.
When not to use it
- The team is in an early, exploratory stage with rapidly changing requirements and infrequent releases.
- A simpler CI setup (automated tests on every push) without full deployment automation may be sufficient initially — the full pipeline's value grows with release frequency and team size.
- Deployments carry significant regulatory or business risk requiring a documented human sign-off.
- Continuous delivery (automated up to a deploy-ready artifact) with an explicit manual approval gate, rather than full continuous deployment with no human checkpoint.
Terms
- Pipeline
- — The automated sequence of stages (build, test, deploy) that runs for each code change, with each stage gating the next.
- Continuous Integration (CI)
- — Automatically building and testing every code change as soon as it's pushed, catching problems quickly.
- Continuous Delivery
- — Automatically preparing every passing change to be deployment-ready, with a manual step for the actual production deploy.
- Continuous Deployment
- — Automatically deploying every change that passes the pipeline, with no manual approval gate before production.
In an interview
A team wants fast automated testing on every push but also wants a human to explicitly approve every production release. Is this compatible with CI/CD, and what's it called?
- yes — this is continuous integration combined with continuous DELIVERY, not continuous deployment
- CI handles the automated build/test on every push
- continuous delivery means the pipeline produces a deploy-ready artifact automatically, but a human explicitly triggers the actual production deploy as the final, deliberate step
Can you recall it?
Why does each stage in a CI/CD pipeline act as a gate rather than running independently and in parallel with the others?