Overlapping customizations across Developer sandboxes
Key Takeaway
When customizations overlap across Developer sandboxes, commit changes to the source repository so that conflicts are identified and merged before work continues.
When several people build customizations at the same time, each person usually works in their own Developer sandbox. Their changes can overlap or depend on each other, and nobody sees the other person's work until it is shared. Teams manage this by tracking each person's changes, merging them in a source control system to catch conflicts, and combining everything in a shared integration sandbox before testing and release.
Why teammates don't see each other's work
Sandboxes are completely isolated from production, so work done in a sandbox does not affect the production org.
On a team with many contributors, each team member gets their own Developer sandbox to build their assigned customization. Developer sandboxes copy metadata only (no production data), can be refreshed every 1 day, and have 200 MB of data storage.
Changes don't take effect in an environment until they are deployed to it, so one person's work is not in a teammate's Developer sandbox automatically.
Teams without a process for sharing and combining this work often struggle with three problems:
- Tracking everyone's changes
- Keeping development and testing environments in sync
- Creating and deploying change sets multiple times because of errors and differences among environments