🔀 Release Management Strategies

Compare different approaches for managing long-running features in a monorepo

The Challenge

The batch merge workflow is the foundation for regular operations — handling small features, bug fixes, and improvements that complete within one sprint. This workflow works well and should remain the default.

But what happens when a feature takes 3+ sprints to complete?

The dilemma: Long-running feature code sits in DEV for weeks, either blocking regular releases or forcing incomplete code into QA/PROD.

The question: How do we handle long-running features while maintaining the regular weekly release cadence for everything else?

Foundation Workflow

Batch Merge Strategy

The default workflow for regular operations. Weekly batch merges from DEV → QA → PROD. All sprint features move together through the pipeline.

  • Simple workflow, easy to understand
  • Weekly release cadence
  • Test failures handled via revert MRs
  • Best for features completing in 1 sprint
 Long Feature Option 1

Feature Flags

For long-running features: All code continuously merges to production, but features are hidden behind runtime flags until ready.

  • No branch divergence
  • Early integration testing
  • Gradual rollouts (canary releases)
  • Best for UI features and experiments
 Long Feature Option 2

Feature Branch + STAGE

For long-running features: Developed in isolated branches, deployed to dedicated STAGE environment until ready.

  • Complete isolation from production
  • Safe for architectural changes
  • Easy to demo or abandon
  • Best for breaking changes

Quick Comparison

Aspect Batch Merge Feature Flags Feature Branch + STAGE
Branch Sync Weekly merges Continuous (no divergence) Manual merges (conflicts)
Integration Testing Weekly in QA Continuous in all envs Late (at merge time)
Risk of Exposure Low (tested before merge) Medium (flag misconfiguration) Low (isolated branch)
Infrastructure DEV, QA, PROD DEV, QA, PROD + flag service DEV, QA, PROD + STAGE
Multiple Long Features N/A (short features only) Easy (separate flags) Hard (separate branches)
Best For 1-sprint features UI features, gradual rollouts Breaking changes, experiments

💡 Recommendation

Primary: Use Feature Flags for most long-running features. The monorepo structure makes branch conflicts expensive, and weekly releases require continuous integration.

Fallback: Use Feature Branch + STAGE only for architectural changes that can't be hidden behind flags (database schema, API contracts). Limit to one feature branch at a time.

Keep: Batch Merge as the default workflow for regular sprint work (features completing in 1-2 weeks).