Test Environments: Managing Dev, Staging, and Production

Test Environments: Managing Dev, Staging, and Production

A well-managed set of test environments enables safe development, testing, and release — each environment serves a specific purpose in the delivery pipeline. Environment management is foundational to quality: tests run in environments too different from production have limited validity.

Environment Hierarchy

  • Development (local): Developer's local machine — full control, fastest feedback loop. May use mocked dependencies. Not suitable for final verification.
  • Development/CI: Shared environment for automated testing — runs test suite on every commit. Ephemeral environments spun up for each test run are ideal.
  • Staging/Pre-production: Production-equivalent environment — same infrastructure, same data structure (not same data), same configuration. Used for final testing before release. Should be as close to production as possible.
  • Production: Live environment serving real users

Infrastructure as Code for Environments

Environments that are manually configured drift from each other — the classic "works on staging, fails in production" problem. Infrastructure as Code (Terraform, Pulumi, CloudFormation) defines all environments from the same configuration templates, ensuring consistency. Ephemeral environments (spun up for a branch, torn down after merge) enable parallel testing without shared environment conflicts.

Test Data Management

Production data cannot be used in test environments — GDPR prohibits it. Maintain synthetic test data sets that represent production scenarios. Data anonymisation tools can create test datasets from production snapshots with PII removed. Ensure critical edge cases are represented in test data.

Did you find this article useful?