Occasionally, it will be necessary to refresh a test/dev environment with a copy of the database from Production. Reasons to refresh test/dev from Prod include:
- Facilitate testing for new configuration
- User training
- In depth research of a critical production issue
This blog post will provide details of the request process, the restore process and steps to make your test/dev system ready for use once the environment is turned back over to you.
Request Process
Support has a template for requesting restores through Launchpad where you must provide precise details to ensure a proper refresh of your test/dev environment. When you create environment refresh request, the following details must be included:
- Source SQL Instance/ Database Name: This will be the url of the source database (Production). The url will be under the System Info link under the ? Icon of the environment that you want refreshed.
- Destination SQL Instance/ Database Name: This will be the url of the destination database (Test/Dev). The url will be under the System Info link under the ? Icon of the environment that you want refreshed.
- Obfuscate (Y/N?): Depending on your internal security requirements, production may be required to be obfuscated (or scrambled) so that names and other data will be unrecognizable.
- Fresh Backup?: Do you want the restore point of the environment to be when support gets the case or will the last backup (or at some other point in time ) be sufficient?
- Purge/Shrink: Customer can also request tables to be purged and shrunk to decrease storage footprint of test/dev environments post restore.
- Other: If you want to the restore to be completed by a certain date, please add this information as well.
Once support has the case, another case be created by support for the dba to perform the restore.
Restore Process
Once the dba has restored the database and reassigned permissions, a set of post-restore “safety scripts” are executed. These safety scripts are designed to prevent the test/dev environment to continue run jobs or process files meant for the production environment.
- File Sweeps: All File Sweeps are set to Open Status so scheduled File Sweep jobs do not get executed
- Scheduled Processes: All Scheduled Process entries are set to Open Status so scheduled jobs (Extracts, Letter Generation, etc) do not get executed.
- Extracts: All Extracts are set to Open Status so they do not get automatically executed.
- Addresses: All email addresses in the Address table are updated with the prefix “invalid_” so that emails do not get sent out from the test system.
- Delivery Targets: All Delivery Targets are deleted so unwanted files/emails will not get automatically sent.
- Options: mail.smtp.host is disabled to prevent emails from going out (including password reset requests).
- Options: ui.logoff.redirect is disabled to prevent users from returning to the production url when logging out of dev/test
- Process notifications: Process notifications are deleted to ensure notifications do not get sent out of test/dev.
Making your refreshed environment ready for use
Once support has turned your environment over for you to use, there are several steps that need to be taken to make sure your refreshed environment is ready to be used. This list is intended to be a guideline and not a complete listing. A list of post restore steps should be developed as part of the implementation process.
Note: Test/Dev environments do not deliver email (other than Password Resets) and extracts/reports without setting the System Environment Level Override flag during Payout and Finalize Payout.
- Options: Activate mail.smtp.host allow password reset emails requests
- FTP Server: Point FTP Servers to Test directories/folders
- Extracts: Activate any extracts that may be needed
- Process Reports: Activate any Process reports that may be needed
Once the above steps are completed, you are ready to begin using your updated environment to continue development or testing activiities.
