How would you handle environments (dev/staging/prod) for different test suite tiers?

Tier 1 — CI runner only. Unit, integration with test-containers (ephemeral DB on the runner), contract tests against mocked dependencies. No external env. Fastest, most isolated, runs on every push. The right place for the bulk of the suite.

Tier 2 — ephemeral environments. For E2E that needs a real backend, spin up a per-PR environment: a Kubernetes namespace, a Vercel preview URL, or Heroku review apps. Pros: full isolation, real prod-shaped infra. Cons: cost, setup complexity, slower start. Use case: feature-branch E2E with a real DB and dependencies.

Tier 3 — shared dev environment. A single env that all devs share. Cheaper, faster than ephemeral, but tests must be tenant-isolated to coexist. Risk: one test breaks the env, all devs blocked. Mitigation: well-isolated test data, fast reset script.

Tier 4 — staging. Closer to prod — same infra topology, sanitised prod-like data, real third-party vendor sandboxes. Nightly E2E and pre-release verification. Less cluttered than dev. Used by humans for exploratory + sign-off.

Tier 5 — production smoke. Read-only, low-risk smoke tests after every deploy. Synthetic monitoring 24/7. Hits real prod with real keys (test tenants). Catches deploy-time issues that staging missed. Critical for continuous deployment.

Decision matrix:

Key rules:

• Never run mutating tests against prod without a tagged-tenant pattern that's explicitly safe.
• Never run destructive tests in shared envs — drop tables, mass-delete users. Wreck your own ephemeral env, not the team's.
• Match data to env — staging needs realistic data shape (volume, distribution). Empty staging tells you nothing about prod behaviour.
• Match secrets to env — test keys for test envs, prod keys only for prod-targeting jobs.

Cost discipline: ephemeral envs are great until the cloud bill arrives. Auto-clean PRs after merge, set TTLs on idle envs, share where you can.