Build & Deployment: Monorepo, CI/CD, Strategies & Release Safety
Frontend build and deployment is not just DevOps — it directly shapes developer velocity, release confidence, cache correctness, and user safety. Key decisions include monorepo vs multi-repo, CI/CD strategy, deployment patterns (rolling, blue-green, canary), feature flags, and observability-driven rollback plans.
Code enters the line (build), passes multiple quality gates (CI checks, tests, previews), gets packaged as an immutable artifact, and is released progressively (canary/blue-green). Feature flags are emergency stop buttons, and rollback is the reverse conveyor belt. The goal is fast, safe, and repeatable delivery.
1Monorepo vs Multi-Repo
Monorepo enables atomic changes, shared libraries, and consistent tooling but requires strong affected-only builds and package boundaries. Multi-repo gives clear ownership and independence but leads to version drift and duplicated effort. Choose based on team topology and shared code needs.
2CI/CD Strategies
Trunk-Based Development enables fast feedback and continuous deployment. GitFlow provides explicit release branches but slows velocity. Strong pipelines include fast PR checks, selective execution, preview environments, and immutable artifacts.
3Deployment Strategies
Rolling: gradual replacement. Blue-Green: instant cutover with fast rollback. Canary: real-user validation with limited blast radius. All require strong observability and rollback plans.
4Feature Flags & Release Safety
Flags decouple deploy from release. Use for gradual rollout, kill switches, and experimentation. Maintain flag hygiene: owners, cleanup dates, and explicit testing of all states.
| Property | Monorepo | Multi-Repo |
|---|---|---|
| Best For | Shared components & design systems | Independent products |
| Velocity | High (atomic changes) | Medium (cross-repo coordination) |
| Ownership | Shared | Clear per team |
| Ci Complexity | Higher (needs caching) | Lower |
Monorepo
Best For
Shared components & design systems
Velocity
High (atomic changes)
Ownership
Shared
Ci Complexity
Higher (needs caching)
Multi-Repo
Best For
Independent products
Velocity
Medium (cross-repo coordination)
Ownership
Clear per team
Ci Complexity
Lower
Common questions
- ›“Monorepo or multi-repo — which would you choose and why?”
- ›“How do you design a safe deployment pipeline?”
- ›“What is the difference between rolling, blue-green, and canary deployments?”
- ›“How do feature flags improve release safety?”
What interviewers look for
- Understanding of trade-offs between velocity and isolation
- Focus on rollback safety, observability, and immutable artifacts
- Knowledge of progressive rollout patterns
- Holistic thinking about developer experience and production risk
Short answer (60 sec)
Monorepo for shared velocity and atomic changes; multi-repo for strong isolation. Use trunk-based development with preview environments, immutable artifacts, and progressive rollout (canary/blue-green + feature flags). Always design for fast rollback and monitor post-deploy metrics.
Detailed answer (senior level)
Build & deployment decisions shape frontend velocity and safety. Monorepos enable atomic changes and shared libraries but require excellent CI caching. Trunk-based development with fast PR checks and preview environments is ideal for continuous delivery. Use blue-green or canary deployments for zero-downtime releases and feature flags to decouple deploy from release. Immutable artifacts and strong observability (error rate, Core Web Vitals, conversion) are essential for safe rollouts.
- Treating build & deployment as purely DevOps concerns
- No preview environments before merge
- Deploying without rollback plan
- Long-lived feature branches instead of trunk-based
- Stale feature flags accumulating technical debt
- ✓Delivery quality = speed + safety
- ✓Monorepo for shared velocity, multi-repo for isolation
- ✓Trunk-based development + preview environments = fast feedback
- ✓Build once, promote the same immutable artifact
- ✓Progressive rollout (canary/blue-green + feature flags) reduces risk
- ✓Always design for fast rollback and observability
- ✓Clean up feature flags and dead code regularly