Replicate prod environment in a lower environment
Overview
There may be circumstances that require you to make a full restoration of your Redpoint Interaction (RPI) production (prod) environment in a lower environment, for example if your production environment is out of sync with lower environments or you want to perform a test on a lower environment using the production configuration. This document outlines the high-level steps you can use to create this copy in a lower environment.
High-level approach
Below are the high-level steps to copy production configuration and assets to a lower environment.
Perform a clean install in lower environment (e.g., Development) configured for all functionality required by RPI prod (e.g., Realtime, Queues, FTP Exports, etc.)
Ensure the new environment has a data warehouse with the same data model as prod
Export configuration and assets from prod
Import into new lower environment
Modify configuration collection objects to point to lower environment resources where needed
1. Install fresh RPI instance in lower environment
Start by creating a new instance of RPI in the lower environment. This environment should contain all of the components that are in prod. So, for example, if you don’t have Realtime or don’t plan to move those assets, then you would not need to install that component.
Reference install documentation:
RPI v6.x: https://docs.redpointglobal.com/rpi/rpi-v6-x-documentation
RPI v7.x: https://docs.redpointglobal.com/rpi/admin-deploying-rpi
2. Use prod data model in new environment
You need to ensure that the new environment is connected to a data warehouse with the same data model as prod, including all tables and views used by RPI. The new lower environment doesn’t need production data (the expectation is that it wouldn’t be prod data), but the data model itself should be the same.
Having the same data model will allow imported items to work without any additional intervention and is the cleanest way to replicate RPI objects to a lower environment.
3. Export/import prod configuration to lower environment
Now that we have a fresh install of RPI set up and connected to a primary data warehouse with the same data model as prod, you can now export the prod objects and import them to the lower environment and then make appropriate updates based on what objects are being transferred.
The document RPI environment configuration and file system migration outlines how to support multiple RPI environments within your organization so that they are all consistent from the lowest environment up through production. The processes and guidelines in that document help you to maintain consistency across all environments by making configuration and system changes in the lowest environment and moving them up to prod systematically. In this case, we will use the same approach to create a clean install with the latest prod configuration and files.
3a. Export from prod
Now you can go into the production environment with an account that has admin privileges and export the various RPI objects.
The process of exporting and importing configuration and file system objects is explained in the Primary types of system objects section of the RPI environment configuration and file system migration topic.
If you’re using RPI v7.3+, the process outlined below is still relevant, but you also have the “Tenant Template Export” feature available, which streamlines the configuration and file system export process and also allows you to export users and user groups.
The high-level steps are as follows:
Copy over system config settings where appropriate and update where needed (v6 approach)
Copy over other configuration objects (v6 approach)
Copy over remaining file system objects (v6 approach)
Configure users and groups for access (in v6, these need to be manually created)
Using Tenant Template Export (RPI v7.3+) for config and file system exports
RPI v7.3 introduced a new feature, Tenant Template Export, that allows you to export RPI objects in a more global way. You can still perform the exports as shown above for v6.x, but the new feature in v7.3+ allows for additional export options. The Tenant Template Export feature and is found in the configuration section of RPI. It allows for additional items to be exported like users, user groups, system configuration settings, etc., as well as the standard file system objects.
The “File System” option extracts all the RPI file system objects as well as the configuration collections. This is a good option if you are trying to replicate an existing environment to a fresh deployment of RPI.
Configuration collections include things from channels to value lists, some of which you may not want to migrate at all or without consideration, given that they will have credentials and potentially point to production resources. In that case, you may want to be more selective when migrating certain collections. Below is a list of collections to think about, and here are some additional details on this topic:
Channels
External Content Providers
FTP Locations
Queue Listeners
Realtime Queue Provider
Migrating certain configuration collections, like the ones listed above, can give the lower environment access to production resources, and in most cases you do not want the lower environment to have this access. To prevent this, you must update them after migration or create new objects with the appropriate access for the environment.
It is always good to consider adding firewall rules to prevent production resources from being accessed by lower environments when certain collections are imported. You may want to consider creating new resources in the lower environment vs. importing them to mitigate any risk of accessing prod resources.
In some cases, like promoting enhancements to an upper system you may want to pick and choose the specific things you want to export, either a configuration collection or the specific files in the file system. You can still do this the same way that is described in the v6.x approach listed above.
3b. Import into lower environment
Now that you have extracted the various objects from the RPI production environment, you can now import them to your lower environment. Below are some references on importing each of the object types independently, and if you are exporting all files using the “Tenant Template Export” you can use either option if you plan to migrate everything.
When migrating production configurations to lower environments, it’s recommended to temporarily block external access in the lower environment. This allows you to safely update any objects that should not point to production resources after they’re loaded, and helps prevent accidental outbound communications.
4. Modify configuration collections
The last step is to modify any configuration collection objects that were brought over and need to be updated so that they don’t point to production resources. The list of objects to review is listed above in this section. Evaluate each one and determine what needs to be done in your specific environment.