Sandboxes, Deployment & Release Management
Sandbox types, change sets vs Metadata API / DevOps Center, and a safe release process.
Admin 2 min readSandboxesDeploymentChange setsDevOps
Sandbox types
| Type | Copies | Data storage | Refresh interval |
|---|---|---|---|
| Developer | Metadata only | 200 MB | 1 day |
| Developer Pro | Metadata only | 1 GB | 1 day |
| Partial Copy | Metadata + sample data (sandbox template) | 5 GB | 5 days |
| Full | Metadata + all data | Same as production | 29 days |
- Developer/Developer Pro for building; Partial for QA with realistic data; Full for UAT, performance and staging.
- Scratch orgs (Salesforce DX) are short-lived, source-driven orgs created from a definition file.
- After a refresh, user emails get a
.invalidsuffix so sandboxes don't email real users.
Moving changes between orgs
| Tool | Notes |
|---|---|
| Change sets | Point-and-click between connected orgs (production ↔ its sandboxes); no deletes; must add dependencies manually |
| DevOps Center | Salesforce's change-tracking UI with Git/GitHub behind it |
| Salesforce CLI / Metadata API | sf project deploy start; scriptable, works with Git and CI/CD |
| Unlocked / managed packages | Modular, versioned releases |
Deploying Apex to production
- Code can't be edited directly in production.
- Deployments run tests: ≥ 75% overall coverage, every trigger covered, all tests passing.
- Test levels:
NoTestRun(sandboxes only),RunSpecifiedTests,RunLocalTests,RunAllTestsInOrg. - Validate (check-only) a deployment ahead of time, then use Quick Deploy during the release window.
A safe release flow
- Build in a Developer sandbox (or scratch org), commit to Git.
- Deploy to an integration / QA sandbox; run automated tests.
- UAT in a Partial/Full sandbox with business users.
- Validate against production days before; fix test failures.
- Quick Deploy in the release window; run smoke tests; communicate changes.
Interview questions
- Which sandbox would you use for UAT with real data volumes? → Full (or Partial Copy if data needs are smaller).
- Limitations of change sets? → Connected orgs only, no destructive changes, manual dependency handling, no version control.
- What's needed to deploy Apex to production? → 75% coverage, triggers covered, passing tests.