Skip to article
← BACK TO DISPATCH
A foreground heap of discarded identical lightweight containers beside one open container in use, a large sealed monolithic chamber sitting ignored and undisturbed in the background.

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.

Get the next dispatch when it drops.

SUBSCRIBE FOR THE NEXT DROP MORE ARTICLES