Overview

PGOS provides powerful DevOps capabilities for games, improves the game operation productivity at every stage. The DevOps Manual will show you how to make efficient use of DevOps tools. We suggest you read the Title & Region Isolation and DevOps sections in Introduction > Design Philosophy to understand the background and design concept.

1. DevOps Pipeline

A typical DevOps Pipeline is shown below. PGOS provides capabilities to allow games to efficiently build their own pipelines. The table below sets out the functions and tools provided for different DevOps stages.

Stage	Functionality / Tool	Description
All	PGOS CLI	A command line interface for game to config title region
	Title Region Sync	Sync between title regions to help the game to deploy and upgrade title regions
code	Local DS	Place DS on local Machine
	Local VS Debugger	Local debugging tool for Virtual Server
build	PGOS SDK	SDK for game client and dedicated server to run game on PGOS
test	Matchmaking Rule Tester	Tester for PGOS matchmaking rule
	Title Region Validation Test	Help game to do testing before title region released to players
release	Title Region Open / Close	Open and Close a title region
deploy	Managed Backend Service	Backend is fully managed by PGOS
	DS Hosting	Auto-scaling dedicated server hosting service
operate	Service Panel	Config pages for every service in the PGOS console
monitor	Dashboard and Alert	Dashboard and Alert pages in PGOS Console

In subsequent articles, we will provide specific recommendations for building your own DevOps pipeline based on PGOS.

2. Key Concepts

1. Title Region

   Title Regions are the smallest isolated units of the game back-end. The configurations and data of different Title Regions are completely independent. Each Title can allocate multiple Title Regions, which can be used to build environments for developing, testing, and releasing. They can also be used to publish games in different countries/regions.

   Different scenarios have different needs for Title Regions, including permission isolation, resource usage, and maximum allowed online users. Title Regions provide a convenient way for management and isolation during the R&D of the game. They can be divided into three categories:

   Name	Usage	Restriction
   Dev Region	Region for Development This region is used as a partition during development. Developers have full control over this partition to modify configurations and upload resources. They can also perform a self-testing in this partition.	A low resource capacity is allocated to this partition, so it only supports a limited number of online users and cannot be used for external release.
   Test Region	Region for Testing This region is the testing partition. The developers, QA team, and DevOps team are granted control over this partition.	A low resource capacity is allocated to this partition, so it only supports a limited number of online users and cannot be used for external release.
   Prod Region	Region for Production This is the partition used for the external release of the game. Only members of the DevOps team with relevant permissions can operate on this partition.	Sufficient resource capacity is allocated to this partition, so it supports a large volume of online users and can be used for external release.

   Games can set up and allocate resources to Title Regions based on their actual needs. Subsequent chapters will provide more detailed guidance.

2. Title Region Open/Close

   Title Regions can be opened and closed at any time. Once a region is closed, players cannot log in. This facilitates the updates and maintenance of the game.

3. Title Region Validation Test

   Before a Title Region is ready for players, the final pre-release test is critical. We call this the Validation Test. When a region is closed, only special QA game clients or player accounts can log in to the game for validation testing.

4. Title Region Export & Import

   To make it easier to save and restore Title Region configurations, we provide the Title Region Export & Import function. You can export Title Region configurations (not including player data) to cache files at any time. Then, you can import the cache files to other Title Regions.Cache files are readable YAML files. You can even modify them before importing. We use YAML files to store cache data so you can manage them with version-control systems such as Git. This way, you can modify Title Region configurations just like writing code and do not have to perform Portal operations.

5. Title Region Sync

   To copy the configuration of one Title Region to another Title Region, besides the Export & Import function, the most efficient way is to use the Title Region Sync function. This allows you to sync configurations among multiple Title Regions without having to worry about cache files.DevOps engineers can use this function to efficiently release and update game versions.

6. Title Region Upgrade & Hotfix

   After you complete the development and testing task in the Dev Region and Test Region, you shall update the latest configurations and builds to the Prod Region. We call this process a Title Region Upgrade.You can use the Title Region Export & Import or Title Region Sync function to update the Dev Region content to the Prod Region. In subsequent chapters, we will describe this process in more detail.

7. Game Data Deletion

   Game Data Deletion means deleting all player-related data in the backend of the game. The operation only deletes data itself but not data definitions and configurations. It is executable only when the title region state is Closed, and only supported in the Dev/Test region. For the Prod region, please contact the PGOS team.