CI/CD explained without the buzzwords — what continuous integration and continuous deployment actually automate, and what a real pipeline looks like end to end.
"CI/CD" gets used as a single buzzword so often that it's easy to lose track of what it's actually automating and why. Understanding the two halves separately — and seeing a real, concrete pipeline — makes it much easier to reason about what to do when a pipeline fails, or how to design one for a new project.
What CI and CD each automate on their own, the typical stages a real pipeline runs through, and a concrete example: the actual pipeline that deploys this project.
CI means: every time code is pushed, an automated process builds it and runs its tests immediately — not once a day, not "before the next release," but within minutes of the change existing. The value isn't the automation itself; it's the speed of feedback. A test failure caught two minutes after a push is a quick fix. The same failure caught two weeks later, after ten more changes have been layered on top, is a much harder problem to isolate.
CD means: once a change passes CI, it's automatically deployed — to a staging environment, or directly to production, depending on how much automated confidence the pipeline has. This removes a specific human failure mode: someone building the right code but forgetting to actually deploy it, or deploying an outdated build by mistake. It does not mean deploying without any checks — it means the checks themselves are automated and must pass before deployment proceeds.
main) starts the pipeline.This site's own deployment flow is a real, working (if intentionally simple) CI/CD pipeline: a git push origin main triggers Cloud Build, which builds a container image from the Node.js/Express application and deploys it to Cloud Run automatically. There's no separate manual "click deploy" step — the push itself is the trigger for the entire build-and-deploy sequence. This is a genuinely minimal but complete CD pipeline: one trigger, one build stage, one deploy stage, and Cloud Run's own startup health check acting as the verification step.
Because a push to main deploys automatically, everything upstream of that push matters enormously — see Git for a Real Website for the full workflow that makes sure only validated, intentional changes ever reach that trigger. For how to make deployment scripts themselves safe to run more than once, see Writing Idempotent Deployment Scripts.
Part of: DevOps Beginners, Cloud Beginners, Second Year