Build & Deployment
CI/CD strategies, deployment patterns, build optimization, and safe release engineering for frontend applications.
Quick Navigation: Monorepo • CI/CD • Deployment • Feature Flags
Architect mindset: Build and deployment decisions are not just DevOps concerns. They directly shape frontend developer velocity, rollback safety, release confidence, cache correctness, bundle quality, and how fast product teams can ship without breaking users.
Monorepo vs Multi-Repo
This is fundamentally a team topology + release coordination decision, not just a Git preference. Choose the model that best fits ownership boundaries, shared code needs, and CI scalability.
Monorepo
Multiple apps, packages, shared libraries, and tooling live in one repository.
🎯 Best For: Shared components, shared contracts, platform teams, design systems, multi-app frontend orgs
Multi-Repo
Each app or service has its own repository and lifecycle.
🎯 Best For: Strongly independent products, separate orgs, isolated services, teams with low shared frontend surface area
Senior Interview Take
- Choose monorepo when you want shared velocity and atomic evolution across apps and libraries.
- Choose multi-repo when organizational independence matters more than shared consistency.
- Monorepo success depends on affected-only builds, caching, ownership rules, and strong package boundaries.
- Multi-repo success depends on stable package publishing, contract discipline, and integration testing across repos.
CI/CD Strategies
Good CI/CD is about short feedback loops and safe delivery. The goal is to detect bad changes early, keep main releasable, and make shipping boring.
Trunk-Based Development
Small, frequent merges into main with short-lived branches and strong automation.
Pros
- ✓ Faster integration and faster feedback
- ✓ Fewer painful long-lived merge conflicts
- ✓ Better fit for continuous deployment
- ✓ Encourages small, reviewable changes
Cons
- ✗ Requires reliable CI and branch protections
- ✗ Incomplete work often needs feature flags
- ✗ Weak test coverage can destabilize main quickly
Best when: You want high deployment frequency and can invest in tests, preview environments, and rollout safety.
GitFlow
Separate long-lived branches such as develop, release, and hotfix, with more formal release management.
Pros
- ✓ Explicit release process
- ✓ Comfortable for teams with scheduled releases
- ✓ Easier mental model for hotfix vs release branches
Cons
- ✗ More branch overhead
- ✗ Higher merge complexity
- ✗ Slower release cadence
- ✗ Can hide integration issues until late
Best when: Releases are tightly controlled, compliance-heavy, or still scheduled in batches rather than continuously.
What a Strong Frontend Pipeline Usually Includes
- Fast checks on every PR: typecheck, lint, unit tests, build validation
- Selective execution: run only affected apps/packages in monorepos
- Preview environments: deploy each PR for product/QA review
- Artifact immutability: build once, promote the same artifact across stages
- Post-deploy verification: smoke tests, error budgets, Sentry, synthetic checks
Deployment Strategies
Deployment strategy is really risk management for production changes. The right choice depends on rollback speed, infrastructure cost, state migration complexity, and observability maturity.
Rolling Deployment
Replace instances gradually so old and new versions coexist during rollout.
Blue-Green Deployment
Maintain two environments and switch traffic when the new environment is ready.
Canary Deployment
Send a small percentage of real traffic to the new version before full rollout.
Production Concerns Senior Engineers Mention
- Backward-compatible APIs: old and new frontends may coexist during rollout
- Cache invalidation: CDN, service worker, and HTML/data cache mismatches can break releases
- Schema migrations: prefer expand-and-contract patterns over breaking changes
- Observability gates: watch error rate, Core Web Vitals, conversion, and API failures
- Rollback plan: define exactly what gets reverted and how quickly
Feature Flags
Feature flags decouple deploy from release. That makes them one of the most important tools for safe continuous delivery, experimentation, and operational control.
Advantages
- ✓Decouple deploy from release: ship code safely, enable later
- ✓Gradual rollout: 1% → 10% → 50% → 100%
- ✓Kill switch: disable risky behavior without a fresh deploy
- ✓Experimentation: run A/B tests or beta access for specific cohorts
Risks
- ✗Flag debt: stale flags accumulate and confuse future changes
- ✗Code-path explosion: too many combinations make reasoning harder
- ✗Testing burden: important flag states must be part of test strategy
- ✗Inconsistent UX: users in different cohorts may see different product behavior
Feature Flag Types
- Release flags: hide incomplete features until ready
- Experiment flags: A/B tests and measured variants
- Ops flags: circuit breakers, kill switches, degraded-mode controls
- Permission flags: beta, internal, premium, or region-specific access
Flag Hygiene Rules
- Every flag should have an owner, purpose, and cleanup date.
- Prefer short-lived release flags; remove them after rollout completes.
- Keep flag checks close to decision boundaries instead of scattering them everywhere.
- Test critical states explicitly: flag on, flag off, and rollout fallback.
Best Practices
- 1.Build once, promote many. The same tested artifact should move across staging and production.
- 2.Optimize the feedback loop. Fast CI matters more than adding every possible check to every PR.
- 3.Use preview environments. Let QA, PM, and design validate behavior before merge.
- 4.Release behind flags when risk is high. Deploying code should not imply exposing it to everyone.
- 5.Monitor after deploy. Error rate, performance, conversion, and API health are part of release quality.
- 6.Design for rollback before rollout. Safe delivery starts with safe reversal.
- 7.Clean up old flags and dead branches of logic. Shipping fast is only good if the codebase stays understandable.