Staging environment

an HCL Commerce staging environment is a runtime environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production environment.

Since online stores can operate 24 hours a day, 365 days of the year, completing maintenance or changes to a site and testing or previewing these changes can be difficult. By using the staging environment, business and technical users can work to prepare, update, and preview changes while isolated from the live store or site on the production environment. This separation allows users to avoid any impact to customers, such as incorrect information or unexpected behavior while customers are browsing store pages.

For example, business users can use the staging environment to complete merchandising or marketing tasks, such as testing the display of new products, prices, and advertisements without affecting the products and pages that customers can view. Technical users, such as developers, can deploy and test changes to JSP pages, EJBs, and commands. After the users verify the changes on the staging environment, the changes can be propagated to the production environment.

The staging environment consists of components that are divided into the following categories:

HCL Commerce application environment

The staging environment is a replica of the production environment. These similarities allow a user to test changes on the staging environment as if it were the production environment. Changes that run correctly on the staging environment, run correctly on the production environment. The staging environment can differ from the production environment in some areas as identified in the following table:

Table 1. Staging environment

summary for complex table
Setup Staging environment Production environment
Hardware (for software that is not run in Docker containers) same same
Software version same same
Operating system version same same
Configuration same same
Nodes The staging environment does not have to have the same number of nodes as the production environment. For example, a production environment can have multiple Transaction server Docker containers while the staging environment can have a single Transaction server Docker container.
Components
Transaction server Docker image same same
IBM HTTP server Docker image same same
Search server Docker image only search-master search-repeater and search-subordinates
Store server Docker image (needed if not migrated from HCL Commerce Version 8) same same
Customization server Docker image same same
Utility server Docker image same same
Database server same same
Database same same

Once the testing completes, a user might want a function to automatically propagate the changes to the production environment. The following two sections describe commands that facilitate this automation.

Staging environment data

There are two types of data: configuration and operation.

Configuration tables

Configuration tables contain data such as stores, catalogs, catalog entries, languages, taxes, and discounts. These tables are under Site Administrator control.

Operation tables

Operation tables contain data such as customer information, address, and orders data.

The staging environment manages only configuration tables. Data in operation tables is not published or copied between the staging and production databases.

Note: It is important to ensure that tables managed by the staging environment do not contain any foreign key references to operation tables. Otherwise, the publication could fail due to a potential primary key deletion from the production database. Before you use the staging environment, ensure that only the organization owns the operational data, not the individual user, such as a catalog administrator.

Delta data capture function

The staging environment uses a delta data capture function to determine which database data changed and needs to be propagated to the production environment. This function is used internally by the staging environment, and no manual intervention is required. The delta data capture function and its ability to identify changes in the production-ready data is a major advantage over a simple test environment.

The delta data capture function does not cover all data in the database. It covers the configuration data, not the operational data.

The data capture function consists of two parts, the staging triggers and the STAGLOG table.

Content data is the static data assets that are fully controlled by the administrator, such as currency, language, product, and catalog. Configuration tables that contain the content data are staging-enabled. Three staging triggers are created on each staging-enabled table to capture the INSERT, UPDATE, and DELETE actions on the staging-enabled table.

These staging triggers log the data changes that happen on the staging tables to the STAGLOG table. Changes are written to the STAGLOG table that is read by the stagingprop command. With the information in the STAGLOG, the staging utility command can propagate the delta data from the production-ready data to the production database.