CodeOath
← All posts
CI/CD & DevOps60 min total · 17 parts

CI/CD Pipelines Explained: From git push to Production

Contents — Part 11 of 17: Why Staging Exists
Part 11 of 17 · ~1 min

Why Staging Exists

Deploying straight from a passing test suite to production skips an entire category of problems: tests mock things (external APIs, sometimes the database, third-party payment providers) that a staging environment — a near-identical copy of production's infrastructure — doesn't. A common pattern:

  1. Merge to main → auto-deploy to staging (low risk, easy to revert, safe to break).
  2. Manually verify on staging, or run additional smoke tests / a full E2E suite against it.
  3. Manually approve → deploy the same build artifact to production.

Staging environments earn their cost specifically by catching the class of bug that only exists at the boundary between your code and the real world it talks to — a third-party API that behaves subtly differently than its mocked test double, a database migration that runs fine against a small test dataset but times out against a production-sized one, a configuration value that's correct in every environment except the one you forgot to update. None of that shows up in a unit test, no matter how good the unit test suite is.