In Virto Commerce, we do not recommend using production data in local/dev/test environments at all.
Firstly, many examples of this have resulted in reputational damage, for example, where an incorrect email notification or payment has been sent from a test system to an entire client population.
Secondly, the level of security, specifically around the protection of private data, tends to be less for test systems. There is little point in having elaborate controls around access to production data if that data is copied to a test database that can be accessed by every developer and QA. Although you can obfuscate the data, this tends to be applied only to specific fields, for example, credit card numbers.
Finally, copying production data to test systems can break privacy laws, for example, where test systems are hosted or accessed from a different country or region. This last scenario is especially problematic with complex cloud deployments.
TOP 5 Recommendations from Virto Team:
- Use Azure Application Insights reports to isolate the problem and get more insights without access to production data.
- Use a clean error message. Every error should provide the reason for it.
- Use Unit and Integrations tests to find and fix the problem.
- Fake data is a safer approach, and tools exist to help in its creation.
- Split Solution Architecture into several subsystems or cells - according to Virto Atomic Architecture™ | Virto Commerce. You will need only a sub-set of the demo data on local/dev/test environments.
We do recognize there are reasons for specific elements of production data to be copied, for example, in the reproduction of complex bugs or for the training specific ML models. Here our advice is to proceed with caution.