#34🚀 DeploymentPainful

Skipping Sandbox and Deploying Straight to Production

“If you didn't test it in a sandbox, you're testing it on your users.”

What Happened

Small change. Just a formula field update. I'd done it a hundred times. Deployed straight to prod from VS Code. Except the formula referenced a field that existed in my dev org but had been deleted in production two weeks ago by another admin. Every record view for that object threw a formula error. Users couldn't open their Accounts. Took 45 minutes to fix because I had to figure out what the formula was even supposed to reference.

The Wrong Way

# "It's just a formula field, what could go wrong?"
sf project deploy start \
  -d force-app/main/default/objects/Account/fields/Risk_Score__c.field-meta.xml \
  -o production
# Field references Commission_Rate__c which was deleted in prod last sprint

The Right Way

# Always go through the pipeline:

# 1. Deploy to dev sandbox
sf project deploy start -d force-app -o DevSandbox --test-level RunLocalTests

# 2. Test manually in dev sandbox

# 3. Deploy to UAT/staging sandbox
sf project deploy start -d force-app -o UAT --test-level RunLocalTests

# 4. Have the client/user test in UAT

# 5. Validation-only deploy to production
sf project deploy start -d force-app -o production --dry-run --test-level RunLocalTests

# 6. Quick deploy after validation passes
sf project deploy quick -o production --job-id <validation-job-id>

The Lesson

There is no change too small for a sandbox test. The one you skip is the one that breaks production.

Share this mistake on X

Don't make this mistake.

Hire someone who already did.

View Consulting →

#33 Running Destructive Changes Before Deploying Replacements Force-Pushing Source That Overwrites Production Customizations #35

Enjoyed this? Get more like it.

Glen's Musings — AI, investing, and building things. Occasional. Free.