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).

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

CodePudding user response：

That sounds like UAT to me, you just don't intend it for users but for yourself. I don't think there is a right answer to this one.

Could be something like UAT-Prod or Demo or you can call it as you wish as there is no standard for it, use whatever helps your team the best.

CodePudding user response：

I have heard this called "Pre-Prod", although it's not as formal of an environment as Dev -> QA -> Staging -> Prod. I most often see Staging take on the role of what you are describing. Although it has "new" code, it has been tested thorough already on the QA environment, and should have all the other integrations and content from Prod, making it closely mirror Prod but with the additions of the code that is about to be merged.

CodePudding user response：

I wouldn't call it a new environment. Its instances of QA and Sandbox set up in a specific way to allow regression testing via direct comparison between the production code and the new code.

Let's lay this out more formally.

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.

This is regression testing. You want to do this as part of your QA step before UAT.

One has the new code pending push to production. It is as close to the production environment as possible, but does not use production data nor services. This would be the same environment you do your manual QA on.

The other is the same thing, but it has the production code loaded. This would be your Sandbox.

The only difference is that you want to be sure both loaded with equivalent test data so you can compare the results. You want to be sure any regressions are due to code changes, and not because the instances are polluted from previous testing.

The procedure would be something like...

1. Get fresh instances of QA and Sandbox.
2. Load your test data into your Sandbox instance.
3. Duplicate the test data to your QA instance and run migrations. *) Alternatively, run equivalent factories or fixtures to generate the same data on both systems.
4. Perform equivalent tasks on your QA and Sandbox and compare the results.
5. Check the results.
6. Reset both instances.
7. If you have more tests, go to 2 and load new test data.
8. Tear down both instances.

You could automate the setup and teardown process so you're always sure you have clean instances to test with.

These aren't environments. They're instances of existing environments which start with equivalent data. You're using them for regression testing via direct comparison. This can be added to QA automation.