CI/CD for Frontend Teams

⏱️ ~3-minute bite · solve the sandbox to master

0%lesson

🧒

5-Year-Old Metaphor

— The physical, real-world picture. No jargon.

🏭 CI/CD pipeline = assembly line quality checks. Bad parts don't ship.

The assembly line analogy

A car factory has inspection stations: weld quality, paint, safety, road test. A car that fails any station doesn't proceed — it stops there for rework. No defective car leaves the factory.

Your CI pipeline is the same: lint (spelling check), typecheck (part fit check), tests (function check), build (assembly), Lighthouse(road test). A PR that fails any gate doesn't merge.

CI — Continuous Integration

• Every PR runs tests automatically
• Lint, typecheck, test, build
• Merge blocked until all pass
• Catch regressions before they reach main

CD — Continuous Delivery

• Merge to main → deploy to staging automatically
• Staging approval → deploy to production
• Feature flags decouple deploy from release
• Rollback = previous deploy, always available

🎛️

Interactive Sandbox

— Move something, see it react instantly.

Pattern

Lint

ESLint + Prettier

0 lint errors

On fail

Block merge

30s

Type Check

tsc --noEmit

0 TypeScript errors

On fail

Block merge

45s

Unit + Integration Tests

Vitest / Jest

All tests pass, coverage > 80%

On fail

Block merge

2–5min

Build

Next.js / Vite / webpack

Build succeeds, bundle budget met

On fail

Block merge

2–4min

Deploy

Vercel / Netlify / Cloudflare Pages

Preview URL live

On fail

Rollback

1–2min

Stage 1/5 — Lint: Fast fail first. Lint catches style violations and obvious bugs (no-console, unused vars) before any compilation. Runs in ~30s. Developers hate waiting for slow CI — lint fast, fail fast.

1 / 5

⚠️ Gotcha: Don't serialize everything. Lint + typecheck can run in parallel. Tests can run in parallel with build (if test artifact not needed for deploy). Sequentializing unnecessarily doubles pipeline time.

💡 Insight: DORA metrics (Deployment Frequency, Lead Time, MTTR, Change Failure Rate) measure pipeline effectiveness. The goal: merge to main → production in <1 hour with >95% success rate.

Completed:🏭👀📦🔦🚩

🎯

Challenge

Step through all 5 CI/CD patterns. Understand what each stage gates and why.

Try it

🎯

Why Should I Care?

— The exact interview question + the bug it kills.

Interview questions

Q: What is the difference between CI and CD?

CI (Continuous Integration): automatically test and validate every code change as it's merged. Goal: keep the main branch always green. CD (Continuous Delivery): automatically deploy validated code to environments (staging, production). With CD, the act of merging is the release decision. Some distinguish Continuous Delivery (automated to staging, manual to prod) from Continuous Deployment (fully automated to prod).

Q: Why run Lighthouse in CI rather than only locally?

Lighthouse scores vary by machine specs. Your M3 Mac gives inflated scores vs a real mid-range Android phone. Lighthouse CI runs against the actual deployed preview URL, with simulated throttling, in a consistent CI environment. It also compares against the main branch baseline — detecting regressions, not just absolute scores.

Q: How do feature flags enable trunk-based development?

Trunk-based development = everyone merges to main frequently (daily or more). Long-lived feature branches cause merge conflicts and integration pain. Feature flags let you merge incomplete features to main behind a flag — the feature is in the codebase but invisible to users. Developers integrate continuously. The "branch" is a runtime if-statement, not a git branch.

🔬

The Deep Dive

— Spec refs, engine internals, the minutiae.

GitHub Actions for frontend CI

1	name: CI
2	on: [push, pull_request]
3	jobs:
4	check:
5	runs-on: ubuntu-latest
6	steps:
7	- uses: actions/checkout@v4
8	- uses: actions/setup-node@v4
9	with: { node-version: '20', cache: 'npm' }
10	- run: npm ci
11	# Lint + typecheck in parallel
12	- run: npm run lint & npm run typecheck & wait
13	- run: npm test -- --coverage
14	- run: npm run build
15	# Upload build for deploy job
16	- uses: actions/upload-artifact@v4
17	with: { name: build, path: .next/ }

DORA metrics — measure pipeline health

Metric	Elite	Low performer
Deployment Frequency	Multiple/day	Monthly
Lead Time to Change	<1 hour	1–6 months
Mean Time to Restore (MTTR)	<1 hour	1 week+
Change Failure Rate	<5%	>15%

Deployment strategies

Blue/GreenTwo identical environments. Switch traffic from blue to green instantly. Rollback = switch back.

CanaryRoute 5% of traffic to new version. Monitor metrics. Gradually increase to 100% or rollback.

RollingReplace instances one by one. Gradual rollout. More complex rollback (some instances on new, some on old).

Feature flagsShip code to all, enable for % of users. Rollback = toggle flag. Works at application level.

🎤

Interview Questions

— Real questions from real interviews — with answers.

CI validates every change automatically; CD deploys validated changes to environments automatically.

Use size-limit in your CI pipeline: define per-entry-point gzip budgets in package.json and fail the build if exceeded.

CI runs against the actual deployed preview URL with consistent throttling; local scores vary by machine and don't catch CDN/build differences.

Flags let you merge incomplete features to main behind a runtime if-check instead of maintaining long-lived branches.

Four metrics quantifying software delivery performance: deployment frequency, lead time, MTTR, and change failure rate.

Capture screenshots of component stories or pages on each PR and diff them pixel-by-pixel against baseline screenshots.

🎮

Memory Game

— Quick quiz — lock the concept in long-term memory.

1/4

Which tool enforces JavaScript bundle size budgets in CI?