CI/CD — let the robots gate every change

On a real team, code is not "done" when it runs on your laptop — it is done when an automated pipeline has built it, checked it, and shipped it without a human babysitting each step. The moment more than one person touches the same codebase, two famous pains appear. The first is "it works on my machine": your code runs fine for you because your laptop happens to have the right library versions, the right environment variables, and that one file you forgot to commit — but it falls over the instant a teammate or a server tries to run it. The second is "merge hell": five people each work in isolation for two weeks, and when they finally try to combine their changes, the edits collide everywhere and untangling them takes days. CI/CD is the discipline — and the automation — that kills both pains. It is a chain of automatic gates that run on every push, so breakage is caught before it reaches your teammates or your users. Master this and you stop being the person who breaks main.

The vocabulary first

Five words do all the work in this lesson, so let us pin them down before anything else:

• A build is the act of turning your source code into something runnable — compiling it, bundling it, installing its dependencies. "The build failed" means that transformation did not even complete, never mind whether the tests pass.
• An artifact is the concrete, finished output of a build that you can store and ship: a compiled binary, a zipped folder of web files, a container image. You build the artifact once and deploy that same artifact to every environment, so what you tested is exactly what runs in production.
• A pipeline is the whole automated sequence — the ordered list of steps that runs from "someone pushed code" all the way to "it is live."
• A stage (or step/job) is one link in that chain: build, lint, test, deploy. Each stage has a job to do and either passes or fails.
• A runner is the machine — usually a fresh, throwaway virtual machine or container spun up by your CI provider — that actually executes a stage. "Fresh" is the point: it starts clean every time, with nothing left over from your laptop, which is precisely why it exposes "works on my machine" problems.

CI vs CD vs Continuous Deployment, untangled

These three terms get used loosely and mean genuinely different things. The difference is entirely about how far the automation goes and whether a human still pushes a button.

The confusing part is that "CD" can stand for either Delivery or Deployment. The reliable way to keep them apart: Delivery stops at a manual approval gate; Deployment removes that gate. Both keep main always releasable — they only differ on who, if anyone, pulls the trigger.

The pipeline is a chain of gates

The single most important mental model is this: a pipeline is a chain of gates, and each gate must pass before the next one even starts. The instant a stage goes red, the line stops — later stages never run, and the failure report points straight at the gate that broke. This is called failing fast: you want the cheapest, fastest checks first so that a typo is caught in ten seconds by the linter rather than after a twelve-minute test suite and a deploy. The first red stage stops the line; everything downstream is irrelevant until you fix it.

Walk each gate and what it catches:

• Checkout — the runner pulls a clean copy of your exact commit from version control. (See Version control on a team for how that commit got there.) Catches: nothing yet — it just sets up a pristine starting point with none of your laptop's leftovers.
• Build — install dependencies and compile/bundle the code. Catches: missing files you forgot to commit, version mismatches, syntax errors that break compilation. This is where most "works on my machine" problems surface, because the runner is clean.
• Lint — a linter is a tool that scans source code for stylistic issues and bug-prone patterns without running it: unused variables, missing await, shadowed names, inconsistent formatting. Catches: the small, mechanical mistakes that humans waste review time on.
• Typecheck — type checking verifies that values are used consistently with their declared types (you do not pass a string where a number is expected, or call a method that does not exist). Catches: whole classes of errors before the code ever runs — the kind that would otherwise blow up at runtime in front of a user.
• Tests — runs your automated test suite; any single red test fails the whole gate. This is the heart of the pipeline. See Testing fluency for what actually goes in here (unit, integration, end-to-end). Catches: behaviour that changed when it should not have — the actual logic regressions.
• Security / dependency scan — automatically checks your dependencies against databases of known vulnerabilities, and may scan your own code for risky patterns and leaked secrets. Catches: a library version with a published exploit, an API key accidentally committed.
• Build artifact — package the verified code into the immutable thing you will deploy (a container image, a zip). Catches: packaging problems; produces the one artifact promoted unchanged through every later environment.
• Deploy to staging — push that artifact to a production-like environment that real users cannot see. Catches: deployment and configuration problems, and lets humans click around in something close to the real thing.
• Manual approval — the optional human gate. Present in Continuous Delivery, absent in Continuous Deployment. Catches: business-timing problems ("not during the holiday freeze").
• Production — the same artifact goes live to real users. After this, your eyes move to observability — you watch the deploy, not assume it worked.

Pipelines are defined as code

You do not configure a pipeline by clicking buttons in a web UI — you write it in a YAML file that lives in the repo, so the build is versioned, reviewed, and rolls back alongside the app. The exact keys differ by vendor (GitHub Actions, GitLab CI, CircleCI), but the shape is universal. Read this one stage by stage; the annotations explain every line:

on: push                   # trigger: run this whole pipeline on every push

stages:
  - name: build
    run: npm ci && npm run build      # clean-install deps, then compile/bundle
  - name: check
    run: npm run lint && npm run typecheck   # style/bug patterns, then type errors
  - name: test
    run: npm test            # fails the pipeline on any red test
  - name: scan
    run: audit-deps --fail-on=high   # block known-vulnerable dependencies
  - name: deploy-staging
    run: deploy ./dist --env=staging # auto-ship the artifact to staging
  - name: deploy-prod
    needs_approval: true   # human clicks "release" → this is the CD gate
    run: deploy ./dist --env=production

Because stages run in order and stop at the first failure, a broken lint never reaches test, and a red test never reaches deploy-staging. Remove the needs_approval: true line and you have just converted Continuous Delivery into Continuous Deployment.

Why fast pipelines matter

Pipeline speed is not a nicety — it changes behaviour. The whole value of CI comes from small batches and fast feedback: tiny changes integrated constantly, each verified in minutes, so a failure has a small "blast radius" (only a few lines could be the culprit). Make the loop slow and people quietly stop using it.

Concretely: with a 4-minute pipeline, you push, glance away, and it is green before you have switched tasks — so you push often, in small pieces, and bugs are caught the same minute you wrote them. With a 40-minute pipeline, you cannot afford to wait, so you batch up many changes to "make it worth a run," push less often, and start merging while it is still running. Now a failure could be hidden anywhere in a huge batch, the feedback arrives after you have mentally moved on, and people begin skipping or working around CI entirely. Same gates, opposite outcomes — the only difference is speed.

Deployment strategies in depth

Getting a green artifact built is only half the job; how you replace the running version matters just as much, because that is where users get hurt if something is wrong. Four strategies, each with how it works, when to reach for it, and — crucially — how you roll back.

Rollback is a first-class safety tool

Notice that every strategy above was described by its rollback story. That is deliberate. The point of all this machinery is not to prevent every mistake — that is impossible — but to make recovery fast and boring. A team that can revert a bad release in thirty seconds will ship confidently and often; a team that cannot will freeze in fear and ship rarely. Rollback ties directly to observability: you deploy, you watch the dashboards and error rates, and the moment something looks wrong you roll back first and investigate afterward. "Revert now, debug later" is the mark of a reliable team.

Where this connects

CI/CD sits in the middle of the engineering-craft story. The artifact the pipeline builds is, more and more, a container image — a sealed box holding your code and its exact environment, so "works on my machine" finally becomes "works everywhere, because everywhere runs the identical box." Once that box is live, the job is not over: you lean on observability to watch the deploy in real time and on your deploy strategy's rollback to recover fast if it goes wrong. And the test gate that anchors the whole pipeline is only as good as the tests in it — which is the subject of Testing fluency.