How Feature Branches Work
Long-running features are developed in separate branches and deployed to a dedicated STAGE environment. When ready, the feature branch merges to DEV and flows through the normal pipeline.
✅ Benefits
- Complete isolation: No risk to production code or regular releases
- Safe experimentation: Can demo incomplete features to stakeholders
- Easy to abandon: Just delete the branch if feature is cancelled
- No flag logic: Cleaner codebase, no runtime conditionals
- Multiple teams: Different teams can work on different long features independently
⚠️ Risks
- Branch divergence: Merge conflicts accumulate over time (especially in monorepo)
- Late integration: Issues discovered only when merging to DEV after weeks/months
- Multiple features problem: If Feature A and B both in STAGE, can't release just one
- Infrastructure cost: STAGE environment = another AWS account + EKS cluster
- Environment drift: STAGE may differ from PROD (data, config, versions)
🛡️ Mitigation Strategies
- Merge DEV → feature branch weekly to keep divergence under 1 week
- Limit to one feature branch at a time in STAGE
- Use feature flags for multiple concurrent long features
- Automated conflict detection (CI job that attempts merge daily)
- STAGE environment parity with PROD (same data snapshots, config)
🎯 Best For
- Architectural changes (database schema migrations, API breaking changes)
- Features requiring extensive refactoring across many services
- Experiments that might be cancelled (don't want code in main branch)
- Teams with strong Git discipline and conflict resolution skills