This concept describes how the synchronization between different environments works. A nearly identical data set on different environments allows for example to run tests under (nearly) production conditions using a lower tier test environment. The sync process can also help to restore the database or sync it from another environment.
After the sync, a pseudonymization process ensures that no sensitive personalized data is stored in local environments.
|SFS||Shared file system|
|UAT||User acceptance test environment|
In contrast to the replication process, which takes place between live and edit ICM clusters, the synchronization process can take place between the edit or live cluster of two environments, for example from PRD edit cluster to UAT or INT edit cluster.
The sync always occurs from a "higher" to a "lower" environment.
Running the sync process is done manually, as this has to be agreed between all parties. An automatic execution (e.g. 1x per week) is also conceivable, but must be individually coordinated for each project.
The synchronization consists of two processes:
This can be done by the customer for INT and UAT environments, not for PRD.
The time required for the synchronization can vary greatly depending on the data stock. A large number of images in particular will increase the time required for SFS synchronization. A large number of products will increase the time required for database synchronization. Also note that the initial synchronization takes longer than subsequent synchronization processes.
The configuration of the two synchronization processes can be done in Jenkins.
The shared file system synchronization can be done in Jenkins via ICM Shared Filesystem Sync.
Below Build with Parameters, the following parameters are available:
The synchronization of the database can be done in Jenkins using jobs "ICM DB MSSQL Backup" and "ICM DB MSSQL Restore".
If ICM DB MSSQL Backup job is not available, then restore can still be made using ICM DB MSSQL Restore as in this case point-in-time recovery is available.
The database backup is scheduled to run automatically and regularly on database level, for example to occur every night or during lowest frequented time of day. It can also be triggered manually by clicking Build with Parameters in Jenkins, if available (see above).
The previously created database backup can be restored in another environment or point-in-time recovery is used to achieve this, see above. For example, a backup from UAT edit database can be restored to INT edit database.
The restoration is done in 5 steps:
The operations team takes care of customer data pseudonymization during the synchronization process.
The operations team also takes care of deactivating automatically running jobs/schedules in order to prevent order exports, etc., for example if the back end target is configured incorrectly (see Limitations below).
Furthermore, the development team is responsible for ensuring that PRD configurations, e.g. regarding Paypal account data, are not identical to those on the UAT environment.
PRD configuration data (service, backend, targets etc.) are also synchronized with UAT. This potentially allows UAT to communicate with PRD backends and possibly execute actions that are not intended for UAT.
The decision on how often the synchronization is done is determined by the customer. Intershop recommends at least one synchronization at the end of each PRD deployment.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.