CI/CD Pipelines Explained: From Push to Production

Part 11 of 17 · ~1 min

Why Staging Exists

Staging earns its keep for snapledger in a way that's almost a direct echo of where this whole story started. The vendor snapledger uses for OCR has a sandbox mode the team's tests run against locally and in CI — cheap, fast, deterministic, and it has never once, in three months, handed back a receipt image with rotated EXIF orientation metadata, because nobody building the sandbox thought to model that. Priya's own Intel Mac, back before any of this pipeline existed, used to produce upside-down results on exactly that class of image, for reasons that turned out to be local environment drift rather than anything about the vendor. Staging is where that same shape of bug shows up again, properly this time: a batch of real receipts, run through the real vendor's real sandbox-adjacent staging endpoint, includes one photographed sideways by an actual employee's phone, and the parsing pipeline mangles it in a way that not one of the mocked unit or integration tests could ever have produced, because the mock simply doesn't know that particular failure mode exists.

No amount of tests against a hand-written stub closes that gap, because the stub only ever returns what someone imagined it should return. Staging is specifically the place where the real world's untidiness — a vendor's undocumented quirk, a slow migration against production-sized data, a config value that's right everywhere except the one environment nobody remembered to update — gets a chance to show up before a customer's bookkeeper is the one who finds it.