Staging server | How staging server works
Staging server introduction
The WebSphere Commerce server application server environment on a staging server is very similar to the production server. The staging server requires exactly the same hardware and software and operating system configuration as the production server. Both the staging and production environments include the WebSphere Application Server, WebSphere Commerce Server, a database server, and a database. The versions of the software and operating systems must also be the same.
- The staging server contains a complete WebSphere Commerce Server instance, just like the production server. Normally, the staging server instance is created on a dedicated machine on your network.
- The staging server environment does not have to have the same number of nodes as the production environment. For example, a production environment may have the database on one physical machine, the WebSphere Commerce Server on another physical machine, and the HTTP server on a third machine. The staging environment can have these three elements on one physical machine.
- From the application content's point of view, the staging server has the same EAR file, the same WAR file, and the same database schema as the production server.
- From the data content's point of view, the staging server has the same JSP pages, HTML pages, Java files, and the same data in the database as the production server.
- From the function's point of view, the staging server has the same function as the production server. Users can perform the same actions on the staging server as they would on the production server. For example, a user can launch the WebSphere Commerce Accelerator, perform a shopping flow, load the database using the loading utilities, or publish a store.
These similarities allow a user to test changes on the staging server as though it were the production server. These tests reassure users that changes that run correctly on the staging server will run correctly on the production server. This is the basic philosophy of the staging server.
The staging server consists of the following components:
- A WebSphere Commerce instance
Tests and modifies your data.
- Database schema scripts
Creates the staging tables and triggers for the staging database. The staging database contains the same schema and tables as the production database, plus a set of triggers to log changes made in the staging database. The staging database schema scripts add triggers to the database. Changes are logged to the STAGLOG table (a staging table) using database triggers. Whenever you change a database table record in the staging database, the STAGLOG table records this change.
- The stage copy utility
Allows an administrator to copy data from the production database to the staging database. You can copy the data into site-related tables, merchant-related tables, or individual tables. The stage copy utility should only be used in specific administrative situations, such as setting up a new staging server or recovery from a corrupt staging server database. An administrator should not make day-to-day changes on the production server or routinely use stage copy to copy the data to the staging server.
- The stage propagate utility
Allows an administrator to propagate changes from the staging database to the production database. The information in the STAGLOG table identifies the records in the staging database that must be inserted, updated, or deleted in the production database. The identified records are then updated in the production database. Processed records are indicated in the STAGLOG table by a 1 in the STGPROCESSED column.
- The stage check utility
Allows an administrator to check for potential unique index key conflicts between two tables on a staging server and a production server.
xxxx