Environment Strategy: Development, Staging, and Production
An environment strategy defines the different environments through which code passes on its way to production — ensuring changes are validated before they reach end users. The number and configuration of environments varies by project size, risk profile, and team, but the underlying principles are consistent.
Standard Environment Tiers
- Local development: Developers run the application on their own machines using Docker Compose or similar tools. Typically uses local databases and mocked external services. Fast iteration, no shared infrastructure.
- Development / CI: Automatically deployed for every code push. Used for automated testing — unit tests, integration tests, end-to-end tests. May be ephemeral (created and destroyed per pull request).
- Staging / UAT: A production-like environment used for final validation before release — functional testing, performance testing, client acceptance testing. Mirrors production configuration but uses test data.
- Production: The live environment used by real users. Changes are deployed here only after successful validation in staging. Protected by deployment approvals and change management processes.
Environment Parity
Staging should be as similar to production as possible — same infrastructure, same configuration, same data volumes (or representative samples). "It works in staging but not in production" is most commonly caused by environment differences: different server sizes, different configuration values, or different data patterns.
Data in Non-Production Environments
Non-production environments should not use real production personal data. We use anonymised or synthetically generated data in staging — protecting user privacy and avoiding GDPR complications.