Make DevOps Pipeline

1. Overview

Since PGOS provides a fully managed back-end for games, DevOps Pipeline is somewhat different from those fully self-developed gaming back-ends.

1. No need to create your own development and testing environments: The game development team can use the Dev Region and Test Region to develop and test the game directly, without deploying their own environments.
2. No need to deploy back-end servers: The development team does not need to deploy back-end game servers. They can simply upload a dedicated server build and set the Title Region configurations to release the game.
3. Game release: The operations team can use the Prod Region to release the back-end for the game directly. No additional tools are required.
4. Game operation: Common operations can be performed on the PGOS Console, such as player profile query management, battle system configuration, and item release and removal.

This article aims to provide simple guidelines and recommendations for DevOps during PGOS game development.

2. Suggestion for DevOps Pipeline

As shown below, we have summarized the main game development process based on practical cases in the past. We will provide relevant pipeline recommendations for each stage.

graph LR A[Plan]-->B[Develop] B --> C[QA] C --> D[Internal Playtest] D --> |Internal Feedback|A D --> E["Public Test<br>(Alpha, CBT...)"] E --> |Feature Validation & Feeadback|A E --> F[Release] F --> |BI Analysis|A

2.1 Development

A typical development process is shown below. Once you create a Dev Region, you can start SDK integration, programming, and debugging process.After you complete debugging, you can perform integration testing directly on the Dev Region, without worrying about deployment as this is automatically done by PGOS.

graph LR A[Get Dev Region]-->B[Integrate SDK] B --> |Console/CLI| C["Config Services<br>(Player,Matchmaking,DS..)"] C --> D[Coding] D -->|Local DS| E[Local Debug] D -->|Local VS Debugger| E[Local Debugging] E -->|Console/CLI|F[Create DS Fleet] F --> I[Test Game<br>on Dev Region] I --> C

2.2 QA

Once the development team completes development and debugging in the Dev Region, you can use the Title Region Sync function to synchronize all Dev Region configurations to the Test Region. This way, the QA Team can perform complete testing in the independent environment provided by the Test Region without interfering with the Dev Region.This mechanism allows the Dev Team and QA Team to work simultaneously, boosting their efficiency.This process is shown below.

graph LR classDef hl fill:#f96; A[Start New Sprint]:::hl-->|Dev Team|B[Coding & Debug<br>On Dev Region] B --> C[Sync Dev Region<br>to Test Region] C --> |QA Team|D[Do Testing<br>on Test Region] D --> E{Test Passed?} E --> |Not|F[Announce Issues] F --------> B E --> |Yes|G[Announce Sprint<br>OK]:::hl

2.3 Internal Playtest

During game development, you may need to perform Internal Playtest in a staged manner. Generally, there is a specific team in charge of testing, and they may have to work with teams on other continents. After the development team produces a playable version, their task is to ensure that players have a good experience of the game in a timely manner. In the traditional development model, the DevOps Team shall deploy game servers in the regions where testers are located. This is a complicated and time-consuming process. When using PGOS for game development, you simply need to use the Title Region Sync function to synchronize all configurations and resources to Test Regions with one click.This significantly improves productivity and reduces the likelihood of human error. The process is shown below.

graph LR classDef hl fill:#f96; A[Version Ready]:::hl-->|Console/CLI|B[Sync Configuration<br>to Test Region] B --> |Steam or Transfer Tool|C[Deliver Client Build] C --> D[Do Playtest] D --> E[Feadback to Dev Team]:::hl

Because PGOS DS Hosting supports cross-region operations, you do not have to use any additional Test Regions. You just need to create a single DS fleet in the region where testers are located and associate the corresponding Matchmaking/Lobby configurations.

2.4 Public Test

Public testing generally involves an Alpha Test and Closed Beta Test. The sample sizes of the tests are different, we recommend using a Prod Region for testing. After completing the test, you can disable or delete this Prod Region to delete the test files. The process is shown below.

graph LR classDef hl fill:#f96; A[Version Ready]:::hl-->|Console/CLI|B[Sync Configuration<br> to Prod Region] B --> C[Validation Test] C --> D[Open Prod Region] D --> E[Announce to Players] E --> F[Players Play Game] F --> |Public Test Completed|G[Close Prod Region]:::hl

2.5 Release or Upgrade

When releasing or updating your game to the public, it is essential to ensure a successful and smooth release process. We recommend performing a Validation Test in a Prod Region before making it available to players. The process is shown below.

graph LR classDef hl fill:#f96; A[Version Ready]:::hl-->B[Close All Prod Regions] B --> |Console/CLI|C[Sync Test Region to<br> All Prod Regions] C --> D[Validation Test<br>on All Prod Regions] D --> E{Validation <br>Test Passed?} E --> |Yes|F[Open All Prod Regions] E --> |No|G[Fix Issues <br>on Dev / Test Region] G --> C F --> I[Announce Upgrade<br> OK]:::hl

2.6 Hotfix

Hotfix is a seamless switch process that allows you to update the game version without any downtime. This process differs significantly between different games, so we cannot provide details. However, when using PGOS, we recommend the following:

• Client version compatibility: If you need to update the game client while ensuring compatibility with different client versions, you shall isolate back-end configurations to ensure the new version does not interfere with the operations of the old version.
• DS isolation: When new and old DS versions coexist and the new DS version is only connected to new clients, you shall isolate the respective Matchmaking, Lobby, and Matchconfig configurations.
• Old version discontinuing: When all clients have been updated, you can remove the resources and back-end configurations for the old version.
• QA: We strongly recommend that you conduct a strict version compatibility testing.