GS2-Freeze

Enterprise feature for fixing the version of GS2 microservices

GS2-Freeze is a feature that allows you to freeze the version of GS2 microservices used by your game at an arbitrary time, and to update the version on a schedule managed by the operator.

Normally, GS2 microservices are continuously upgraded, and games always use the latest version of the API. While most titles operate without issue under this model, there are situations such as right after the release of a large-scale title, or when stability is to be prioritized for a long period of time, where the operator wants to control the timing of service-side updates. GS2-Freeze is an enterprise feature designed to meet such needs.

Tip

GS2-Freeze is an enterprise feature and is not broadly provided to all customers. If you would like to use it, please contact support.

Stage

The central concept of GS2-Freeze is the “Stage”. A stage represents “a set of GS2 microservice versions frozen at a specific point in time”.

The following information is associated with each stage.

Stage name (name): A name that uniquely identifies the stage
Source stage name (sourceStageName): The name of the stage from which version information is sourced
Sort number (sortNumber): A number representing the order of stages such as development, verification, and production
Status (status): The state of the stage (promoting, rolling back, etc.)

By specifying the stage to use when calling GS2 APIs, the game client and server can use the version of the microservices frozen on that stage.

graph LR
  Latest["Latest GS2 Microservices"] -- Promote --> StageDev["Stage: dev"]
  StageDev -- Promote --> StageStg["Stage: staging"]
  StageStg -- Promote --> StageProd["Stage: production"]
  Game["Game Client"] -- API Request --> StageProd

Promote / Rollback

The operation of updating the version of a stage is called “Promote”. When promote is executed, the version frozen on the source stage is copied to the target stage. For example, “promoting the version of the staging stage to the production stage” reflects a verified version to production.

If a problem is discovered after promotion, you can execute a “Rollback” to revert to the previous version.

Promote and rollback can take time, and are executed asynchronously internally. The progress of the operation is recorded as Output, and the state can be checked later.

Sort order of stages

By using sortNumber, you can arrange multiple stages in a hierarchy such as “development”, “staging”, and “production”. The sort order is used as a hint for the display order on the management console and for selecting promotion targets.

Transaction Actions

GS2-Freeze does not provide transaction actions.

Master Data Management

Because stages themselves are operational configuration information in GS2-Freeze, the typical “import / export of master data” found in other microservices is not provided. Stage creation, update, and deletion are performed via the management console or GS2-Deploy.

Example Implementation

GS2-Freeze is a microservice centered on management APIs. No dedicated Domain class is provided in the game engine SDKs (Unity / Unreal Engine).

Operations such as stage creation, promotion, and rollback are not intended to be called directly from the game client; we recommend operating via one of the following means.

Management console
GS2 CLI
General-purpose SDKs for various languages (C# / Go / Python / TypeScript / PHP / Java)
Template management via GS2-Deploy

For details on each SDK, see the corresponding reference page.

More practical information

Three-stage operation: development, verification, and production

A representative usage pattern is to prepare three stages for development, verification, and production, and promote them in order from left to right.

Development stage (dev): Uses the latest GS2 microservices to verify new features.
Verification stage (staging): Promotes versions that have been verified on the development stage, and performs QA and rehearsals.
Production stage (production): After confirming quality on the verification stage, promotes the version and serves it to game players.

With this operation, even if a new GS2 release is made, you can reflect it in production only at the timing desired by the game operator.

Immediate rollback when issues occur

If a defect is found after promoting to the production stage, you can execute rollback to immediately revert to the previous version. Because you can revert just the service-side version without making changes to the game itself, it is useful as an option for emergency response.