Is there some sort of formalized name for a deployment environment that is essentially a copy of production with NO new code?
All the environment names I’m used to, deal with the concept of moving new code/schemas/configurations forward through each of the environments until ultimately reaching production (i.e. Dev → Test / QA → Staging → Prod, or whatever combo you might have) with qa testing tools.
While this makes sense, I’ve come across a situation where I often need to test against production (same code, roughly the same DB state, etc.), but because I don’t want to impact production, I need a sandbox to play in. The impetus for this is I’m usually comparing QA / Test against Prod to make sure there are no regressions and that the new functionality implemented doesn’t result in some unexpected result.
Unit tests catch some of this, but sometimes it helps to simply have 2 browser windows open and navigate against 2 separate sites doing the same functionality and making sure everything is working the same after a major upgrade.
Back to my question: Is there a name for this? Perhaps “Sandbox” is good enough. I’m surprised I don’t see this type of thing referenced in searches or on the Wiki for Deployment Environments
In the past this was called the acceptance test environment. This term might still be used in regulated companies.
A modern term is green environment. In the mean time the blue environment is used for production. If the green environment is ready for production, then the roles of the environments are switched:
Staging
We then have “Integration” in front of that, notably do we have other dev environments, but those share any uninteresting resources between themselves and are not copies at all.
I’ve observed a team who decided to call it “production” even though it was a separate environment, and lived on development infrastructure. IT CAUSED ALL HELL. Because people make a bunch of assumptions about it, and try to delete and decommission it or do things to it, based on their preconceptions.
That is probably why testers have to make checks not just on the product, but also checks on the process changes and also have to run checks on the people we work with.
