What is CI/CD? From Manual Deploys to Pipelines
Before CI/CD, shipping code usually meant someone manually running tests, building the app, and copying files to a server, slow, error-prone, and something only whoever "knows the deploy steps" can safely do. CI/CD automates that entire path from commit to running in production.
Continuous Integration (CI)
CI means every change gets automatically built and tested the moment it's pushed, catching integration problems (two people's changes conflicting, a change breaking existing behavior) within minutes instead of days.
Push code → CI server checks it out → installs deps → runs tests → reports pass/fail
The core promise of CI: nobody merges code that doesn't pass the automated checks, so main stays in a known-good state.
Continuous Delivery vs. Continuous Deployment
These two terms are often confused, and the difference matters:
| Term | What happens after CI passes |
|---|---|
| Continuous Delivery | A deployable build is produced and ready to ship, a human clicks a button to actually release it |
| Continuous Deployment | Every change that passes CI is deployed to production automatically, no human in the loop |
Both require the same underlying automation (build, test, package), Continuous Deployment just removes the manual approval step entirely, appropriate once you trust your test suite and rollback process enough.
Why automate this at all
- Speed: changes reach users in minutes/hours instead of a scheduled weekly release.
- Consistency: the exact same automated steps run every time, no "it worked on my machine" deploy.
- Confidence: a broken build is caught immediately, by CI, not discovered by a user in production.
- Auditability: every deploy has a record of exactly what changed, what tests ran, and who approved it.
NOTE
"Pipeline" is the general term for the sequence of automated steps (build → test → package → deploy), and it's the central concept the rest of this course builds on, concretely, with GitHub Actions.