PROD restore into DEV environment - yay or nay?
Hi,
My process has always been to do a PROD restore in STG before I migrated any big package up so that I had a dress rehearsal before I went to PROD. My management wants to also do a PROD restore in our DEV environment. I have been hesitant for a few reasons listed below. Do you do this or not and either way, why?
1. Lose ability to see which specific fields within an application were updated since all fields look updated on the package date in STG or PROD
2. Lose ability to see who made the change because the name of the person who migrated the package is everywhere in STG and PROD instead
3. Lose ability to see which are OOTB fields that say created by System Administrator
Anything else I missed?
a community member?
-
Hi Katie!
When you say “restore”, are you doing a full DB restore on that environment, or are you just “packaging down” from Prod to STG?
Andrea
0 -
Full DB restore but I am open minded to other suggestions
0 -
Depending on the complexity of your environments, and how many "beyond the box" things you do with feeds, Custom Objects, APIs, etc... Restoring the PRD database to UAT and DEV on a regular cadence is almost a must to keep the object GUIDs / IDs in sync between environments, and the benefits IMHO outweigh the negatives you noted above.
0 -
I currently have 60 active data feeds, 1 custom object (submit button), and no APIs yet. I generally follow the rule that if it is a new field, it needs to be packaged up from DEV through PROD, but I am guilty of building reports manually all the time without packaging so those guids don't match.
0
Please sign in to leave a comment.
Comments
4 comments