Vulnerability in EPiServer.Forms
I am currently working in a context where we use 3 development environnments : DEV, TEST and PROD. DEV and TEST are basically only used by testers and developers to test their development features, so contain only fake datas.
For some tests purpose of advanced search functionnalities on our website, we would like to have concrete datas on TEST to be able to search, ideally reflecting the PROD datas the closest possible.
So basically, we would like to replace the TEST EPiServer's DB with the one from PROD. Application is the same, using the same EPiServer's version, etc.. Only the DBs are different.
I suggested my network team to simply backup the PROD DB and then restore it on TEST (replacing the existing one), but then they're not confident because the PROD DB from EPi contains PROD references like URLs and host names that they don't want to move on TEST. We are afraid that TEST environment then start to impact the PROD one.
Is there an existing process to perform this migration the best way? Should I select only a specific set of tables to move from one DB to the other? Is there any EPiServer's tool to perform this kind of operation?Because basically those are just the contents and types that we woule like to move from one DB to the other, not the settings and access rights for example.
Thnaks to anybody that could bring some light on this, I would be very grateful!
I normally copy the entire prod database (and appData files like images) to create/update stage server (which is basically your test). Normally you want to restrict outgoing emails though to only send emails to a white list from stage. You will need to change host in admin of course after moving the database. You might have some content that points to production but normally this is not a big problem. If you store urls to integrations (like url endpoints) in Episerver you might want to move those to web.config instead.
Other options are:
1. Export/Import site from admin (works sometimes...)
2. Setup mirroring between the sites. (usually more trouble than it's worth...)
3. Create fake data with a big red button in admin mode programmatically. Sometimes a good idea. I use it in a few projects. Take a while to setup well though so normally only worth the effort in larger projects.
Thanks so much for your input Daniel!
Your suggestion is basically what I suggested. We have prepare a SQL script to apply on TEST to anonymize the datas like emails as you mention. For files, I sugeested to move from the PROD file system to the TEST file system in order to avoid broken images and files references.
Moreover, we already performed this kind of operation from TEST to DEV for example, and I have to admit that we didn't face any issue of mixing environment or mixing datas. It's just that we want to be sure that moving from PROD to TEST will not impact PROD at the end in this case.
Regarding your endpoints remark, all the endpoint we use on external services are set in Web.config file and already specific to each environment, so no worries regarding this.
Regarding your other other suggestions :
So the only way for me is still to copy the entire DB as you mention and then adapt the hosts and stuffs I guess!
Anyway, thanks again to share your experience, best regards.