Skip to article
← BACK TO DISPATCH
A fresh blank account ledger open beside a stack of identical blanks, the bound archive blurred far behind.

Scratch-org-first as a deploy discipline

The first time I pushed a half-shaped metadata manifest straight to a shared sandbox, I cost my team an afternoon. The org was dirty from a previous sprint, the error message made no sense, and rolling back took longer than the deploy itself. Expensive. And completely avoidable.

The discipline I settled on: scratch org first, always. A scratch org is disposable. It doesn't care what you broke last sprint. If the manifest is malformed, you find out in minutes against a clean slate, not hours into a shared environment three other people are actively working in. Fast feedback, and when it's bad news, you bin the org and start over. No cleanup ritual, no awkward Slack message.

What changed the speed even further was breaking the validate step by metadata type instead of throwing the full manifest at once. A monolith failure gives you a wall of errors and no obvious entry point. A typed chunk that fails? That's your answer. One re-run, one needle.

Earn the right to touch a persistent org by first proving it works against a disposable one.

That's the whole thing, honestly. Gate ordering, promote sequencing, rollback rules. Different post. If you've built something like this, I'm curious what you'd change.

Part of Salesforce Architecture

Get the next dispatch when it drops.

SUBSCRIBE FOR THE NEXT DROP MORE ARTICLES