Managing Parallel Project and Support Releases in Salesforce
Running big planned project releases alongside a steady stream of urgent production fixes (P1s, P2s and so on) needs decisions made up front about environments, branching and how you deploy. What you are guarding against is support work getting stuck behind the slower cadence of a major project release.
Environment strategy
The main project stream usually runs Dev -> SIT -> UAT -> Pre-Prod -> Prod. Support fixes need environments that sit close to production but still let you iterate fast.
Recommended environment mapping
| Stream | Development | QA/Testing | Staging/Integration |
|---|---|---|---|
| Project | Project Dev Orgs (Feature Branching) | SIT Sandbox(es) | UAT Sandbox(es) |
| Support | Support Dev Org / Sandbox | Shared UAT (Validation) | Shared Pre-Prod |
Sharing Pre-Prod between the last stage of support fixes and the final validation of the major project release only works with strict change control windows. If your support fixes are volatile or complex, a separate Support Staging environment is the better option, at the cost of more maintenance.
Handling support fixes: hotfix vs. support dev stream
Where an urgent production bug fix (P1) goes depends on its scope and on what is already scheduled to deploy.
- Standard support dev process, which is what I would use for P2s, P3s and non-critical P1s. Fixes follow the normal flow: Dev -> QA -> UAT -> Pre-Prod -> Prod, so they get regression tested against the current baseline, including any project code already merged into UAT and Pre-Prod.
- Dedicated hotfix org, for critical P1s. Use a hotfix sandbox only for immediate fixes to critical business functionality, where waiting even one cycle is unacceptable.
Hotfix org usage guidelines
- Keep the scope surgical. A hotfix addresses the defect and nothing else. No enhancement work, no refactoring.
- Refresh the hotfix org from Production immediately before you build the fix, so the baseline matches current production metadata.
- Any metadata you deploy from a hotfix org to Production must go straight back into the active project development branch, or the appropriate Support Dev Org. Skip that and the bug returns with the next major deployment.
# Example Back-Merge Process using SFDX
sfdx force:source:pull -r HotfixOrg
sfdx force:source:tracking:clear --sourcepath force-app/main/default/classes/CriticalBugFix.cls
sfdx force:source:deploy -p force-app/main/default/classes/CriticalBugFix.cls -t ProductionOrgAlias
Synchronization and cadence
Set clear release cadences so project work does not block urgent fixes, or the other way round:
- Project cadence: fixed intervals for major deployments, say every 4 weeks. Changes freeze and merge into a Release Branch in the run-up to that date.
- Support cadence: fast deployment windows for validated support fixes, daily or a few times a week depending on the SLA.
Pre-Prod has to stay synchronized. When a support fix is promoted there, tell the project team. If the project is actively testing in Pre-Prod, support validation either pauses or moves to a separate UAT/QA environment for final sign-off.
The Project Release Branch must pick up every production fix the support stream deployed before the final deployment to Production. Miss the back-merge and the large project deployment overwrites the production metadata, taking those critical support fixes with it.
Leave a Comment