What is CI/CD — and why a green checkmark promises nothing

Here's a funny one: an empty repo with CI set up goes green every single time. No checks, nothing to fail. The checkmark is there, and the code could be anything at all.

That's the first thing worth understanding about CI/CD. A green checkmark doesn't say "the code works." It says: "the exact checks you wrote have passed." Not one more.

Let's unpack what this robot is, why you want one, and what to put inside it so the checkmark starts meaning something.

What CI/CD means in plain words

CI/CD is a robot that lives next to your repo. It wakes up on every commit and does what you already do by hand: installs dependencies, runs tests, builds the project.

One difference: it does this every time. Not when it remembers. Not when you skip it because "eh, I only fixed a typo, no need to check."

That typo is usually the thing that breaks.

The robot isn't smarter than you. It just never gets tired or lazy. Everything it knows, you wrote yourself — usually in an instructions file inside the repo.

How it works: commit → the robot wakes up

The flow is simple, and it's nearly identical everywhere:

1. You push a commit or open a pull request.
2. The service spots the new commit and spins up a clean machine from scratch.
3. On it, it runs your list of steps: install, lint, build, test.
4. If any step fails — red X. All pass — green checkmark.

The key word is clean. The robot starts fresh every time, with none of your local mess. None of your hidden files, none of that package you installed once and forgot.

That's how CI catches the classic: "works on my machine, nowhere else." It works on yours because your laptop has something extra. The robot doesn't have it — so it fails, honestly.

CI and CD are two different letters

People write them with a slash, and beginners read it as one word. They're two separate habits.

CI — Continuous Integration. Every change gets checked automatically. Tests, linter, build. CI's job is to stop a break from leaving your laptop.

CD — Continuous Delivery/Deployment. If the checks pass, the robot ships the new version itself. CD's job is to kill the manual deploy ritual.

Always start with CI. CD without CI is a robot that ships broken code to production very quickly and very reliably.

Why you want this even working solo

The word "integration" comes from big teams: there, CI reconciles code from ten people. You're alone, nothing to reconcile — so it sounds like someone else's problem.

It's your problem for three reasons.

You will forget to run the tests. Not because you're bad, because you're human. Friday evening, "I just changed one string" — you won't want to check. The robot doesn't ask what it wants.

You write code with AI. The model produces plausible code faster than you can read it. CI is the net that catches plausible-but-broken before production. There's a whole piece on why that happens: why AI-written code has bugs.

It's nearly free. Public repos on GitHub Actions don't get their minutes counted at all. Private repos have a free allowance — around 2,000 minutes a month on the free plan, and past that the price is fractions of a cent per minute. Your side project won't hit that ceiling.

What to put in your first pipeline

Don't build the pipeline of your dreams on day one. The first one is three steps, and it's more honest than it sounds:

1. Install dependencies. Already useful: catches a broken lockfile and packages that exist only on your machine.
2. Run the linter. Seconds of work, catches typos and dead imports.
3. Run the tests. Even if there's exactly one.

And here's where the trap from the intro shows up. While your repo has zero tests, step 3 passes instantly and always. The checkmark is green. The meaning is zero.

So CI has one simple rule: a checkmark is worth exactly what your checks are worth. Want it to mean something? Add checks, not badges. You can write those first tests with a model: how to write tests with AI.

One more thing worth keeping: a red CI isn't a shame, it's an evening saved. The robot fell over instead of your users.

How is CI/CD different from deploying?

Deploying is a single action: ship the new version. CI/CD is a habit where the deploy comes last, and only after the checks. You can deploy without CI/CD (by hand), and you can have CI with no deploy at all (checks only).

Do I need CI/CD for a small side project?

CI — yes, the minimal version: three steps, ten minutes of setup. CD — no rush. While you're solo and shipping weekly, a manual deploy isn't a problem. Automate what you do often and find boring, not what's fashionable.