Beyond which environments I use on different project/organisation there is one recurrent strategy that I have applied several times in different context. I may say it is a pattern.

The problem

Like any pattern explanation it should start with a problem, so here it is: it is very common production environments to be large in term of hardware capacity and also in size of data. This makes difficult (and/or very expensive) to replicate the production environment to test your application. If you test in an environment different from the production environment you are taking a risk, and the bigger the difference is the higher the risk you are taking.

The solution

Your application pass through different environments from you local development machine to the final production environment.  These two environments are the extremes of your pipeline, so you should make use that each intermediate environment is «closer» to the production environment.

Example

Local development environment (your workstation): here you run the whole application in an isolated way, you have a local DB installed and external services dependencies may be mocked. Your hardware is not comparable to production’s hardware. Even your OS may be different: you may use Windows 10 or Mac or Ubuntu Desktop, while your production server may run Windows Server or Ubuntu Server. In terms of the previously mentioned dimensions, all of them are different from production.

Development environment: your hardware is still far from production, but at least you have the same OS asp production but the other dimensions are still different.

Test Environment: here your layout is the same as production, that is: if you have a cluster for the production DB, then you also have a cluster for test DB but possibly your test DB cluster has less servers that the production one.

This way the closer to production the more Production-like, Complex and Expensive.