Colony-by-colony upgrade in a sharded deployment

Review the section for the strategy for upgrading one or more colonies in a sharded deployment, without upgrading all the colonies. In a sharded environment, multiple colonies can run on multiple versions of Sterling Order Management System Software. This enables you to maintain different enterprises on different versions of Sterling Order Management System Software.

For example, you can deploy colony 1 on Sterling Order Management System Software Release 10.0, and colonies 2 and 3 on Release 9.5. The enterprise in colony 1 runs on Release 10.0, and the enterprises in colonies 2 and 3 run on Release 9.5. All the enterprises in colonies 2 and 3 maintain their own separate transaction/master data. However, because enterprises on the same version of Sterling Order Management System Software can share configuration and statistical data with each other, the enterprises in colonies 2 and 3 share configuration and statistical data.

In this example, the colony-by-colony upgrade strategy can be either used to upgrade colony 1 to Release 10.0, or used in the future to upgrade colonies 2 and 3 to Release 10.0.

The colony-by-colony upgrade strategy provides the advantage of upgrading one or more colonies in a sharded deployment, while other colonies in the deployment remain in production. There is no loss of production time for colonies that are not being upgraded. Similarly, enterprises are maintained at different versions and are upgraded without the production time for other enterprises in the deployment being affected.

Note: If you are using the DEFAULT colony's transaction shard in your production environment, you cannot use the colony-by-colony upgrade strategy. You must upgrade all colonies together at once.

The colony-by-colony upgrade process involves the following major tasks:

  1. Create an upgrade environment.
  2. Move the colonies that you are upgrading from the production environment to the upgrade environment.
  3. In the upgrade environment, run a full sharded upgrade.
  4. Return the upgraded colonies from the upgrade environment to the production environment.
    • Typically, history data and transaction data are migrated separately as part of the upgrade process. When migrating data, production is down for the deployment. The colony-by-colony upgrade strategy provides instructions for migrating history data and transaction data using this data migration process. However, Sterling Order Management System Software provides the yfs.api.history.disable property and the yfs.api.history.disable.colony.<colony_id> property, which allow you to migrate history data when the application is running on the transaction data.
    • When upgrading a colony, all participating organizations must also be upgraded. If a participating organization is located in a different colony, both colonies must be upgraded. Participating organizations include nodes, inventory organizations, capacity organizations, catalog organizations, and so on.
    • You must use the same technical stack in Sterling Order Management System Software Release 10.0, that was used in Release 9.5. A technical stack includes the application server, JDK, and database server.

"Colony-By-Colony Upgrade: An Example" describes a scenario in which one colony from a sharded deployment containing three colonies is upgraded from Release 9.5 to Release 10.0.