Creating a staging server on a migrated environment
You can create a staging server after migrating your WebSphere Commerce environment.
Procedure
- Run stagingprop to ensure that all your latest changes are available on the production server.
-
Back up your staging trigger definition of your custom tables as well as their corresponding
records in the following tables: STGMERTAB, STGSITETAB, and STGMRSTTAB.
If you are not sure about your staging triggers, check the WC_installdir/schema/db_type/wcs.stage.trigger.sql file, where db_type is either db2 or oracle.
- Migrate your production server.
-
Create a WebSphere Commerce instance as a staging server:
- Start the WebSphere Commerce Instance Creation wizard.
- Complete the pages of the wizard.
- On the Staging page of the wizard, ensure that you select Use staging server. If you do not select this check box, the resulting WebSphere Commerce instance is a production WebSphere Commerce instance.
- Ensure that caching is not enabled in the Cache page.
When the instance creation process completes, you have created a staging instance. -
Redefine your custom tables in the staging database schema.
- Place the backed up records into the STGMERTAB, STGSITETAB, and STGMRSTTAB table, depending on the scope of the table.
-
Redefine your staging triggers for the custom tables in the
wcs.stage.trigger.sql file.
Note: Do not run the wcs.stage.trigger.sql file or change the wcs.droptrigger.sql file.
- Run stagingcopy to synchronize the staging database with the production database.
- Modify the wcs.droptrigger.sql file to include all the custom tables after running the stagingcopy utility.
- Publish a sample store on the staging server that is the same store type as the store on your production store.
- Copy the nondatabase assets such as JSP files, JavaScript files, and image files, from the production server to the staging server. For more information, see the following topics: Copying files to the staging server, and Deploying customized assets.