Build & Deployment
Frontend delivery is a safety system: build deterministic artifacts, verify them quickly, release deliberately, observe production, and keep rollback boring.
Quick Navigation: Mental Model • Pipeline • CI Gates • Release Strategies • Cache Safety • Interview Framing
Deployment Is Risk Control
A frontend deployment is not just “run build and upload files.” It changes what users load, which assets are cached, which API contracts the app expects, which feature paths are visible, and how quickly the team can recover from a bad release.
Determinism
Same commit, same dependencies, same build output. If the artifact changes between environments, debugging becomes guesswork.
Blast radius
Release strategies control how many users are exposed before confidence increases.
Recoverability
Rollback is part of the design, not a panic button added after the incident.
Strong engineers separate deploy from release. Deploy means code exists in production infrastructure. Release means users can experience the behavior.
The Frontend Delivery Pipeline
The pipeline should answer one question at each stage: what risk are we reducing before the change reaches more users?
Build artifact
Goal
Create one immutable output from a known commit.
Failure mode
Rebuilding per environment creates drift and makes rollback harder.
CI gates
Goal
Reject unsafe changes before they reach users.
Failure mode
Slow or noisy checks train teams to bypass them.
Preview
Goal
Expose the exact change to reviewers before merge or release.
Failure mode
Preview environments without production-like config miss real integration bugs.
Release
Goal
Move traffic deliberately with limited blast radius.
Failure mode
Deploying code and releasing behavior as the same event increases risk.
Monitor
Goal
Detect regressions through errors, performance, and business signals.
Failure mode
A green deploy with no observability is just an assumption.
Rollback
Goal
Return users to a known-good state quickly.
Failure mode
Rollback fails when data, cache, or API changes are not backward-compatible.
CI Gates Should Be Fast and Meaningful
Continuous integration should keep the default branch releasable. The hard part is not adding checks; it is choosing checks that fail for real reasons and finish quickly enough that developers respect them.
| Gate | Catches | Tradeoff |
|---|---|---|
| Typecheck + lint | Invalid contracts, unsafe patterns | Fast signal, but cannot prove runtime behavior. |
| Unit/component tests | Logic and user-visible UI behavior | Good feedback, but mocked boundaries can hide integration bugs. |
| Production build | Bundler, route, asset, and compile issues | Essential but slower than pure code checks. |
| End-to-end smoke | Critical journey wiring | High confidence, but expensive if every scenario runs on every commit. |
| Performance budget | Bundle and loading regressions | Needs realistic thresholds; noisy budgets get ignored. |
In monorepos, affected-only builds and remote caching matter because CI cost grows with the dependency graph. Without task graph discipline, a monorepo becomes one large slow project instead of many coordinated ones.
Release Strategies and Blast Radius
Deployment strategy is about how quickly you expose users and how quickly you can reverse the decision. The safest strategy depends on infrastructure, observability, data compatibility, and product risk.
Rolling deployment
Best for: Routine low-risk changes where mixed versions can safely coexist.
Tradeoff: Efficient and common, but rollback is slower and compatibility matters during rollout.
Blue-green deployment
Best for: Fast cutover and fast rollback when duplicate environments are affordable.
Tradeoff: Great for validation, but data/session migration can still be the hard part.
Canary release
Best for: Risky changes where real-user validation matters before global rollout.
Tradeoff: Limits blast radius, but needs routing, monitoring, and clear stop criteria.
Feature-flag rollout
Best for: Separating deploy from release, cohorts, beta access, and kill switches.
Tradeoff: Powerful safety control, but stale flags create long-term complexity.
Cache and Version Compatibility
Frontend rollback is harder than it looks because users do not all load the same files at the same time. HTML, JavaScript chunks, CSS, images, data caches, CDN state, and service workers can each point to different versions.
- HTML and JavaScript chunks from different releases can mismatch if cache headers are wrong.
- Service workers can keep serving old assets after a new deployment.
- CDN invalidation may fix one layer while browser cache still holds another.
- API and frontend versions can overlap during rollout, so contracts must be backward-compatible.
Practical rule: cache immutable hashed assets aggressively, but keep HTML and deployment manifests fresh enough that the browser discovers the right version graph.
Feature Flags Separate Deploy From Release
Feature flags let teams ship code without exposing behavior to everyone immediately. They support beta cohorts, kill switches, experiments, and progressive rollout. They also add state space: every important flag state needs ownership and cleanup.
Good flag hygiene
Owner, purpose, rollout plan, metrics, cleanup date, and a tested off state.
Bad flag hygiene
Permanent flags, scattered conditionals, unclear ownership, and untested combinations.
Rollback Is a Product Requirement
A rollback plan is only real if it handles the parts that do not roll back cleanly: migrations, cached assets, client-side storage, service workers, background jobs, and API contract changes.
Rollback checklist
- Can the previous artifact be redeployed without rebuilding?
- Are API changes backward-compatible with old and new clients?
- Can risky behavior be disabled with a flag before redeploying?
- Do dashboards show whether rollback actually restored user health?
Interview Framing
A strong answer connects build and deployment to user risk. Do not stop at “CI/CD runs tests.” Explain artifact determinism, preview environments, release controls, cache compatibility, monitoring, and rollback.
Senior answer pattern
I would build an immutable artifact from a known commit, run fast CI gates, deploy a preview for review, promote the same artifact through environments, and release risky behavior behind flags or canaries. After deployment I would monitor errors, performance, and product metrics, with a rollback path that accounts for caches, API compatibility, and migrations.
Key points to mention
- Build once and promote the same artifact across environments.
- Keep main releasable with fast CI, preview environments, and branch protections.
- Use feature flags or canaries when deploy risk is higher than routine.
- Watch errors, Core Web Vitals, conversion, and API failures after release.
- Plan rollback before rollout, especially when caches, schemas, or API contracts change.