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.
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"?
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.