How Batch Merge Works
The foundation workflow for regular operations. Features that complete within one sprint move through DEV → QA → PROD in weekly batch merges. All sprint work flows together through the pipeline.
✅ Benefits
- Simple and predictable: Easy to understand, everyone knows the weekly cadence
- Minimal branch divergence: Weekly merges keep environments in sync
- Clear testing phases: Analyst tests in DEV, business tests in QA
- Controlled releases: All cards must be approved or reverted before production
- Traceable history: Revert MRs create clear audit trail for failures
⚠️ Limitations
- All-or-nothing merges: All sprint work moves together, can't release individual features
- Revert overhead: Failed features require revert MR and re-enter next cycle
- Blocking releases: One failed feature can delay entire sprint release
- Not suitable for long features: Features taking 3+ sprints block the pipeline
🔄 Key Workflow Points
- DEV environment: Analyst tests features immediately as they're deployed
- Weekly DEV → QA merge: All tested features move to QA environment together
- QA environment: Business performs UAT, analyst verifies integration
- Test failures: Revert MR removes failed code, card returns to In Progress
- Release gate: QA → PROD merge only when all cards approved or reverted
- Merge order: DEV → QA blocked until QA → PROD completes (prevents mixing cycles)
🎯 Best For
- Bug fixes and small improvements (complete in days)
- Features that complete within 1-2 sprints
- Teams with predictable sprint velocity
- Organizations requiring clear release approval gates
⚡ When to Use Alternatives
- Feature Flags: When feature takes 3+ sprints and can be hidden behind runtime flag
- Feature Branch + STAGE: When feature requires architectural changes (database schema, API contracts)