Change Management and Deployment
Moving metadata
Know the vehicles. Change sets move metadata between a sandbox and production over a deployment connection: outbound from the sandbox, inbound to production, with dependencies tracked and missing components flagged. They cannot delete components, cannot carry every metadata type (many settings and data are excluded), and are subject to size and component limits. Metadata API, Salesforce CLI, and VS Code handle source-format deployments, destructive changes, and automation. Unlocked packages version and upgrade internal apps; managed 2GP packages are for AppExchange distribution. Scratch orgs with source tracking are the source-driven model, and DevOps Center sits on top of it.
Sandbox facts
Developer and Developer Pro refresh daily; Partial Copy every 5 days and holds roughly 5 GB of data drawn from a sandbox template; Full Copy refreshes every 29 days with all data. Choose Partial Copy for realistic data subsets and Full for UAT and performance testing.
Traps
- 75% org-wide Apex coverage is required, and tests in the deployment must pass unless explicitly skipped.
- Change sets do not carry destructive changes or all settings; delete via CLI/Metadata API.
- Deploying a component whose dependency is missing fails - deploy the dependency first or package them together.
- Refreshing a sandbox overwrites it entirely; anything created there is lost.
Worked example
Shipping a field, a validation rule, and a flow: deploy the field first, then the rule and flow, and expect missing-component errors if the flow references a field you left out.