Environments (Dev, Test, Staging, Production)

The usual environments

Environment	Purpose	Data	Who uses it
Local / Dev	Writing and trying out code	Fake or small samples	You
Test	Automated and manual testing of changes	Prepared test data	Developers, testers
Staging	Final check in a setup as close to production as practical	Anonymised or synthetic copies	Team, sometimes stakeholders
Production	The live system	Real data	Real users

Names and the number of stages vary between organisations. Some skip staging; others add extra ones for performance or acceptance testing.

What differs between them

• URLs, credentials, feature switches and log levels differ. This is why configuration lives outside the code (see Environment Variables).
• Each environment has its own secrets, and production secrets are far more restricted (see Secrets Management).
• Real personal data should not be copied into lower environments (see Data Privacy Awareness and Test Data Management).
• Fewer people can change production, and changes are traced.
• Lower environments are often smaller and talk to sandbox versions of external systems.

Keeping them similar

Differences between environments hide bugs: something works in test and fails in production. Keep the same operating system, versions and deployment method everywhere, and let only configuration differ. The twelve-factor article calls this dev/prod parity.

Avoiding accidents

• Check which environment you are connected to before running anything that changes data.
• Promote the same build through the environments and do not rebuild it for each one (see Build vs Run vs Deploy).
• Never test with production credentials, and never debug by editing files directly on a production server.

Try it

For a project you work on, list its environments and fill in the table above: URL, where its configuration comes from, who can deploy to it, and what kind of data it holds. Note one difference between two environments that could plausibly cause a bug.