How to Set Up CI/CD for a React App

Here is a pattern I see constantly. A developer can build a polished React app: clean components, sensible state, nice animations. Then someone asks, "Okay, how does this actually get to production?" and things go quiet.

It is not a knowledge problem. It is that most of us learn React by running npm run dev and never think hard about the path between our laptop and a live URL. That path is CI/CD - and it also happens to be one of the most common system-design questions in frontend interviews, so it is worth getting right twice over.

The good news: the pipeline for a React app is genuinely simple once you see it as a single straight line. This post walks that line end to end, the way I actually wire it up in a real project - with interactive demos so you can run each stage yourself.

Continuous Integration (CI) means every time you push code, a machine runs your checks for you: install dependencies, lint, type-check, run tests, build. If anything fails, the change is blocked before it can merge. You stop "integrating" once a week in a painful big-bang merge and instead integrate constantly, in small safe steps.

Continuous Delivery / Deployment (CD) is what happens after the checks pass. Continuous Delivery means the build is always ready to ship and a human clicks the button. Continuous Deployment means there is no button: merge to main and it goes live automatically. Most React teams start with Delivery and graduate to Deployment once they trust their tests.

Why does this matter for a React app specifically? Frontend bugs are loud and public. A broken build, a type error that slipped through, a 4 MB bundle, a blank white screen on mobile. CI catches these before users do. CD makes sure the fix ships in minutes, not after someone is free to run a manual deploy.

Do not memorize tools. Memorize the flow. Tools change (Vercel, Netlify, GitHub Actions, GitLab CI), but the stages are always the same:

Read it left to right. The first half (up to build) is CI: prove the change is good. The second half is CD: get the good change in front of people, first on a private preview, then in production. Monitoring and rollback close the loop so a bad release is a 30-second fix, not an outage.

It starts before any automation. You never commit straight to main. You branch (feat/checkout-button), push, and open a pull request. The PR is where CI runs and where humans review.

Then you turn on branch protection for main: require the CI checks to pass, require at least one approval, and block force-pushes. This single setting is what turns "we have tests" into "you cannot merge code that breaks the tests". Without it, CI is just a suggestion.

In an interview, mentioning branch protection and required status checks signals you have actually worked on a team, not just solo side projects. It is a small detail that carries a lot of weight.

This is the heart of CI. Drop one file at .github/workflows/ci.yml and GitHub runs it automatically. Here is a production-quality workflow for a Vite or Next.js React app:

A few things worth calling out. npm ci (not npm install) installs exactly what is in your lockfile, so CI is reproducible. The cache: npm option in setup-node caches dependencies between runs, which usually cuts a couple of minutes off each build. And every step runs in order, failing fast: if lint fails, you never waste time on the build.

A pipeline is only as good as the checks inside it. Here is what each gate does and the bug it stops:

Start with the first four; they are cheap and catch the majority of issues. Bundle size, audit, accessibility, and Lighthouse are the ones that separate a hobby setup from a professional one, and they are exactly what a strong interview answer reaches for.

This is the feature that makes frontend CI/CD feel magical, and Vercel and Netlify give it to you almost for free. When you open a PR, the platform builds your branch and posts a unique preview URL right in the PR.

The value is huge and underrated. A designer can check spacing on the real site instead of a screenshot. QA can click through the actual flow. A product manager can sign off on the feature without pulling the branch and running it locally. Everyone reviews the same deployed artifact, not their own mental model of it.

In an interview, this is a great point to make: "I would set up preview deployments so review happens on a real URL, not on a diff." It shows you think about the whole team, not just the code.

Once the PR is green and approved, you merge to main. That merge is the trigger. With Vercel or Netlify connected to the repo, a push to main automatically builds and deploys to production. With GitHub Actions, you add a deploy job that runs only on main and only after the verify job succeeds.

The non-negotiable rule: production deployment is a consequence of merging good code, never a manual command someone runs from their machine. Deploying from a laptop means deploying uncommitted changes, the wrong branch, or a build no one else can reproduce. The pipeline is the only thing allowed to ship.

Optionally, you gate production behind a manual approval (Continuous Delivery) for high-risk apps, or let it flow automatically (Continuous Deployment) once your test suite earns that trust.

A green pipeline tells you the code built and passed tests. It does not tell you the feature works for a real user on a slow phone in production. That is what monitoring is for, and it is the part most developers forget to mention.

Wire up error monitoring (Sentry or similar) so a runtime exception pages you instead of sitting silently in a user’s console. Add performance monitoring to catch a regression in load time. Keep logs you can actually search.

Then have a rollback plan. On Vercel and Netlify, every deploy is immutable, so rolling back is one click to a previous build, seconds, not a panicked revert-and-redeploy. Feature flags take it further: ship code dark, turn the feature on for 5% of users, and kill it instantly if metrics dip without any redeploy at all.

"I’d start with branch protection on main so nothing merges without passing checks and a review. Every push and pull request triggers a GitHub Actions workflow on Node 20 that installs with npm ci, then runs lint, type-check, tests, and a production build, failing fast at the first broken step. On top of that I’d add a few high-value gates: bundle-size limits, a dependency audit, accessibility checks, and Lighthouse CI for performance.

For deployment I’d connect Vercel or Netlify so every PR gets a preview URL, which lets designers, QA, and product review the real thing before it merges. Production only deploys after CI is green and the PR is approved and merged to main, never from someone’s laptop. After release I’d watch it with Sentry for errors and real-user performance monitoring, and keep rollback to one click using immutable deploys, with feature flags for risky changes. The whole point is that every push can confidently answer one question: is this safe to ship?"

I have seen every one of these in real codebases. Each is a small shortcut that quietly removes the safety the pipeline was supposed to give:

You do not need all of this on day one, and saying so in an interview shows judgment. But here is the path from "good" to "production-grade", roughly in the order I would add them:

Strip away the tools and the YAML, and CI/CD is one idea: every change earns its way to production by passing the same checks, every time, automatically. No heroics, no "works on my machine", no Friday-afternoon deploy anxiety.

That is also why it is such a good interview question. It is not really testing whether you know the name of a GitHub Action. It is testing whether you understand how software safely reaches users.

So whether you are wiring this up for a real project or explaining it across a table, anchor everything to one question. Every push should be able to answer it: is this safe to ship?