What CI/CD is for, and what it prevents

You have code in Git, an app in a container, and somewhere to run it (a Kubernetes cluster). The last gap is the path from a commit to running software — and doing that by hand, every time, is slow, error-prone, and the source of a surprising number of outages. CI/CD automates that path so that pushing code leads, reliably and automatically, to tested, deployed software. This module builds a real pipeline. This first lesson is what CI/CD is, and the specific problems it prevents.

What the letters mean

CI — Continuous Integration. Every change is automatically built and tested as soon as it is pushed, so problems are caught immediately, on every commit, rather than piling up.
CD — Continuous Delivery / Deployment. The tested change is automatically prepared for release (Delivery — ready to deploy at the click of a button) or actually released to production (Deployment — no human step). Which "D" a team uses depends on how much they automate the final release, but both mean: getting a change to users is an automated pipeline, not a manual ritual.

Put together, CI/CD is an automated pipeline from commit to running software: push code → it builds → it tests → (if green) it deploys. The whole point is that this happens the same way every time, without someone remembering the steps.

The problem it solves: manual is slow and dangerous

Consider deploying without CI/CD. Someone, on their laptop, pulls the latest code, runs the build, runs the tests (if they remember), builds the image, pushes it, SSHes to the server, and restarts things — a dozen manual steps, in order, from memory. This is a disaster waiting to happen:

Steps get forgotten. "I didn't run the tests" / "I deployed the wrong branch" / "I forgot to build the image" — every skipped step is a potential outage.
It's slow and it's a bottleneck. Only the person who knows the steps can deploy, so releases are rare and large, which makes each one riskier (the more changes in a release, the more can go wrong).
It's inconsistent. Two people deploy slightly differently; "it worked when I did it" becomes a mystery.
Problems are found late. If code is only built and tested occasionally, a bug introduced on Monday might not surface until Friday's deploy, tangled up with everyone else's changes — expensive to find and fix (the cost-of-bugs idea).

Manual deployment does not scale and does not stay reliable. CI/CD replaces the ritual with a script that runs the same way, every time, fast.

What CI/CD gives you

Automating the pipeline changes how a team works:

Every change is verified automatically. The build and tests run on every commit and every pull request (the Git module's PR checks), so a regression is caught on the change that caused it — before it merges, before it reaches anyone.
Deployments become small, frequent and boring. When deploying is one automated pipeline, you deploy often — many small, low-risk releases instead of rare, terrifying big ones. Frequent small deploys are safer, because each contains little, and a problem is easy to pinpoint and roll back.
The process is consistent and repeatable. The pipeline does the same steps every time, on a clean machine, so "works on my machine" and "I forgot a step" disappear.
Anyone can deploy — or nobody has to. The knowledge is in the pipeline, not one person's head, removing the bottleneck and the single point of failure.
Fast feedback. You learn within minutes whether your change is good, while it is fresh in your mind.

This is why CI/CD is a defining DevOps practice: it is the mechanism that lets a team ship quickly and safely, which used to be a trade-off. The rest of this module builds one — a real GitHub Actions pipeline for the greetings app that tests it, builds its image, and deploys it — and the deployment-strategies lesson makes those releases zero-downtime.

The shape of a pipeline

Every CI/CD pipeline is a sequence of automated stages, and they are much the same everywhere:

Trigger — something starts it: a push to a branch, or a pull request opened.
Build — compile/prepare the app and build the container image.
Test — run the automated tests (unit, integration); if any fail, the pipeline stops and nothing is deployed.
Deliver/Deploy — if everything passed, push the image to a registry and deploy it (to staging, then production).

The crucial property is the gate: a failure at any stage stops the pipeline, so broken code cannot reach production. Tests failing means no deploy — automatically, every time, without anyone deciding. That gate is what makes the automation safe rather than just fast: it is not "deploy whatever was pushed", it is "deploy only what passed". Hold that shape — trigger → build → test → deploy, with a hard gate on failure — and every CI/CD system you meet is a variation on it.

Check your work

CI = every change automatically built and tested on push (catch problems immediately, per commit). CD = the tested change automatically prepared for release (Delivery — one click) or released (Deployment — no human step). Together: an automated pipeline commit → build → test → deploy, the same way every time.

The problem it solves: manual deploys (a dozen from-memory steps on someone's laptop) forget steps (outages), bottleneck on one person (rare, large, risky releases), are inconsistent, and find problems late. Doesn't scale or stay reliable.

What CI/CD gives: every change verified automatically (caught before merge), small/frequent/boring deploys (safer — little per release, easy rollback), consistency (clean machine, no forgotten steps), no person-bottleneck, fast feedback. Lets a team ship fast and safely.

Pipeline shape: trigger (push/PR) → build (app + image) → test (stop if any fail) → deliver/deploy. The gate — failure stops the pipeline — is what makes automation safe: deploy only what passed, automatically.

Practice

Define CI and CD in your own words, and explain what the pipeline automates end to end.
List four concrete problems with manual deployment and how CI/CD fixes each.
Explain why small, frequent deploys are safer than rare, large ones.
Explain the "gate" in a pipeline and why it makes automation safe rather than just fast.
Draw the four stages of a typical pipeline and what each does.
Explain how CI/CD removes the single-person deployment bottleneck.

Official documentation

GitHub — About continuous integration — CI with GitHub Actions.
Atlassian — CI/CD explained — CI vs continuous delivery vs deployment.
Martin Fowler — Continuous Integration — The practice and why it matters.

Next: GitHub Actions — workflows, jobs and steps.