Actions
Edge Case Handling – Hotfixes, Rollbacks, Emergency Releases¶
This page defines how to handle non-standard scenarios without corrupting sprint or release data.
- Table of contents
- Edge Case Handling – Hotfixes, Rollbacks, Emergency Releases
Case A – Production Hotfix (Outside Sprint)¶
Scenario¶
- Critical production bug
- Cannot wait for next sprint
Correct Handling (DO THIS)¶
Issue Creation
| Field | Value |
|---|---|
| Tracker | Bug |
| Work Type | Bug Fix |
| Status | In Progress |
| Sprint Version | Not set |
| Release Version | Release 2.5.1 – Hotfix |
After Fix¶
- Status → Done
- Deployment Reference URL added
- Status → Closed
- Release Version marked Closed
Why This Works¶
- Sprint metrics remain clean
- Full production traceability
- Clear audit trail
bq. Do NOT backfill into sprint
bq. Do NOT create fake sprints for hotfixes
Case B – Hotfix with Sprint Follow-up¶
Scenario¶
- Immediate patch required
- Proper fix planned later
Correct Handling¶
1. Hotfix issue:
* Release Version only
2. Follow-up work:
* New Story
* Work Type = Tech Debt
* Planned through normal backlog and sprint
This separates urgency from correctness.
Case C – Rollback Release¶
Scenario¶
- Release deployed
- Rolled back due to issues
Correct Handling¶
- Do NOT reopen completed issues
- Create new Bug(s)
- Work Type = Bug Fix or Platform
- Assign Release Version:
Release 2.5.1 – Rollback Fix
Why¶
- History remains immutable
- Rollback is recorded as an event, not a rewrite
Case D – Partial Release¶
Scenario¶
- Some stories ready
- Others delayed
Correct Handling¶
- Release Version contains only: * Accepted * Deployed stories
- Delayed stories: * Have no Release Version * Planned into next release
- Clean release notes
- No ambiguity
Updated by Redmine Admin about 2 months ago · 1 revisions