Managing Parallel Project and Support Releases in Salesforce
Architecting a system that handles substantial, planned project releases alongside continuous, urgent production support fixes (P1s, P2s, etc.) demands a clear strategy regarding environments, branching, and deployment methodology. The core challenge is ensuring support velocity is not bottlenecked by the slower cadence of a major project release.
Environment Strategy
The typical progression involves Dev -> SIT -> UAT -> Pre-Prod -> Prod for the main project stream. Support fixes require environments that mirror production closely while allowing rapid iteration.
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 |
Key Consideration: Sharing the Pre-Prod environment between the final stages of support fixes and the final validation stage of the major project release requires strict change control windows. If support fixes are highly volatile or complex, dedicating a separate Support Staging environment is preferable, although this increases maintenance overhead.
Handling Support Fixes: Hotfix vs. Support Dev Stream
The decision regarding where to deploy an urgent production bug fix (P1) depends on its scope and the existing deployment schedule.
- Standard Support Dev Process (Recommended for P2/P3/Non-Critical P1s): Fixes follow the standard flow: Dev -> QA -> UAT -> Pre-Prod -> Prod. This ensures proper regression testing against the current baseline (including any project code merged into UAT/Pre-Prod).
- Dedicated Hotfix Org (For Critical P1s): A dedicated Hotfix Sandbox should only be used for immediate fixes impacting critical business functionality where waiting even one cycle is unacceptable.
Hotfix Org Usage Guidelines
- Scope Limitation: Hotfixes must be surgical—addressing only the defect. No enhancement work or refactoring should occur here.
- Metadata Isolation: The Hotfix Org should be refreshed from Production immediately before the fix is implemented to ensure the baseline matches current production metadata.
- Mandatory Back-Merge: Any metadata deployed from a Hotfix Org to Production must be immediately merged back into the active Project Development branch (or the appropriate Support Dev Org) to prevent reintroduction upon 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
To prevent project work from blocking urgent fixes, and vice versa, establish clear release cadences:
- Project Cadence: Define fixed intervals for major deployments (e.g., every 4 weeks). Changes are frozen and merged into a Release Branch leading up to this date.
- Support Cadence: Define rapid deployment windows for validated support fixes (e.g., daily or multiple times per week, depending on SLA).
Synchronization Point: The Pre-Prod environment must be kept synchronized. When a support fix is promoted to Pre-Prod, ensure the Project Team is aware. If the project is actively testing in Pre-Prod, support validation must pause or utilize a separate UAT/QA environment for final sign-off.
Managing Merges: The Project Release Branch must incorporate all production fixes deployed via the Support stream before the final deployment to Production. Failure to back-merge ensures that when the large project deployment overwrites the production metadata, those critical support fixes are lost.
Key Takeaways
- Establish distinct development environments or utilize strict branching strategies to isolate parallel workstreams.
- Utilize Hotfix Sandboxes sparingly for immediate P1 resolution, ensuring mandatory back-merging into the main development pipeline.
- Synchronization at the Pre-Prod stage is critical; implement governance around validation windows if environments are shared.
- All production fixes deployed via a hotfix path must be integrated into the mainline development branch before the next large project deployment to prevent metadata regression.
Leave a Comment