Field Notes
When staging lies: environment parity before the next promotion
A release can be green for weeks and still fail in production if staging never exercises the same migrations and flags.
Most rollback postmortems start with a surprise. Staging was green. Production was not. The gap is rarely mystical — it is usually seed data, feature flags, or migration ordering that staging never saw.
What to compare first
Walk the last successful production promotion beside the staging counterpart. List differences in:
- Database migration path and seed assumptions
- Feature flag defaults at promote time
- Secrets and config keys that only exist in one environment
- Job timeouts and retry counts
A parity check that fits a sprint
Add a dry-run job that applies production-bound migrations against a staging-shaped dataset restored from a scrubbed snapshot. It does not need to be perfect on day one. It needs to fail in staging when the ordering is wrong.
Ownership
Parity checks die when they belong to “the platform” and everyone. Name one engineer who owns the dry-run job and one product lead who owns flag defaults at promote time.
PineBase uses this comparison in Deployment Pipeline Advisory walkthroughs because it surfaces concrete defects faster than abstract maturity models.