What is it?
CI (continuous integration) runs your tests + lint + build on every push. CD (continuous deployment) ships the result automatically when CI passes. Together they turn "deploy" from a scary manual ritual into something that happens dozens of times a day, safely.
Why it matters
The deploy pipeline is the team's safety net and velocity engine. A broken main branch with no CI is a team that ships slowly and nervously. Preview deploys — a unique URL per PR — change how teams review work. Hiring teams expect you to know this exists and roughly how it works.
What to learn
- CI basics: what runs on push (lint, typecheck, test, build)
- GitHub Actions: workflows, jobs, steps, the YAML model
- Deploy targets: Vercel, Netlify, Cloudflare — push-to-deploy
- Preview deployments: a live URL per pull request
- Environment variables: build-time vs runtime, secrets management
- Branch protection: require CI green before merge
- Rollbacks: how to undo a bad deploy fast
Common pitfall
Putting secrets in client-side environment variables. Anything prefixed
NEXT_PUBLIC_ (or VITE_) ships to the browser in plain text. API keys,
database URLs, and tokens must stay server-only. A leaked key in a
client bundle is a real, common, expensive mistake.
Resources
Primary (free):
- GitHub Actions docs · docs
- Vercel — Deployments · docs
- Next.js — Environment variables · docs
Practice
Take any project on GitHub. Add a GitHub Actions workflow that runs lint + typecheck + build on every PR. Connect the repo to Vercel for push-to-deploy and preview URLs. Open a PR with a deliberate type error and watch CI block it. Done when CI gates merges and every PR gets a preview URL.
Outcomes
- Write a GitHub Actions workflow that runs your checks on every push.
- Set up push-to-deploy with preview URLs per pull request.
- Store secrets server-side, never in client-exposed env vars.
- Roll back a bad deploy without a panic.