Debug and Deployment Tools
Debugging tools
Debug logs are available from the Developer Console, VS Code and the Setup log viewer. Logs have per-category levels (Apex, Database, Workflow, Validation, Callout, System) and a size cap - setting everything to FINEST usually truncates the part you need. System.debug() writes at the DEBUG level unless you pass a LoggingLevel. Checkpoints in the Developer Console capture heap state at a specific line; the Apex Replay Debugger replays a saved log file in VS Code so you can step through execution offline. Execute Anonymous runs from the Developer Console, VS Code or Workbench. The Limits class reports consumption within the current transaction.
Deployment tools
- Change sets move metadata between related orgs, are outbound-only, and cannot delete components - deletion requires a destructive changes manifest through the Metadata API.
- Metadata API / Salesforce CLI (SFDX) supports source-driven development, validation-only deployments and destructive changes.
- Sandboxes: Developer, Developer Pro, Partial Copy and Full differ in data included and refresh interval.
- Order matters: dependencies must exist - objects before fields, fields before layouts, classes before flows that reference them.
Traps
A validation deployment runs tests too, so a deployment fails if coverage drops below 75%. Debug logs are transient and capped in size. A change set cannot carry standard-object customizations you never added, and it cannot remove a field. Reading a failure log top-down usually saves time: the first error causes the cascade below it.
Rule of thumb
Always validate against a sandbox first, then deploy. If a deployment fails, fix the first dependency error and re-run rather than guessing at the rest.