[bob1029]

Yes we have a 2 stage process with the customer. There is still a test & production environment, but test talks to all production business systems too. Only a few people are allowed into this environment. We test with 1-5 users for a few days then decide to take it to the broader user base.

[__jem]

> but test talks to all production business systems too

I'm not sure I understand this, would you mind explaining more? Do you mean you have multi-tenancy in databases and application (the "tenants" being stage/test and prod)?

[pm90]

I think what op’s referring to is a staging app version that talks to production services and databases. Eg you have a “clone” of your production UI, accessible only to devs. This clone is configured to talk to the same DB and call the same dependencies as the production service but since it’s access is limited it’s used by devs to test their new feature(s).

This pattern is used where I work too. It’s been incredibly powerful. Some of our services allow for multiple staging replicas so that nobody is blocking one another; the replicas are ephemeral and nuked after testing.

[__jem]

Right but I'm wondering how you avoid polluting your production dataset with test data, hence the question about multi-tenancy in the database. Do you use a different schema? Discriminator column? How do you know the data came from the "clone"?

[bob1029]

Yes. This is essentially the idea.

[erhk]

This is how to build a scaling DoS issue that bombs prod iirc