diff --git a/i18n/zh/docusaurus-plugin-content-docs-kruisegame/current/best-practices/workflow.md b/i18n/zh/docusaurus-plugin-content-docs-kruisegame/current/best-practices/workflow.md
new file mode 100644
index 000000000..d2005dc29
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs-kruisegame/current/best-practices/workflow.md
@@ -0,0 +1,215 @@
+# 游戏运维工作流最佳实践
+
+## 背景
+
+由于游戏服务器有状态的特性，对于游戏运维而言，通常需要根据当前业务状态进行相应处理，以避免玩家体验受损。OKG提供了游戏服务器状态感知和定向管理的能力，具备根据不同状态进行不同处理的前提条件。在实际生产过程中，一个运维流程是多个运维动作的组合，运维工程师往往需要进行“游戏服状态确认” → “游戏服操作”的往复动作，这也导致游戏服云原生化后依然存在一定的操作复杂度。
+
+本文将结合“房间服无损发布”这一实际场景，向读者展示如何通过Argo Workflow将对GameServerSet和GameServer的运维动作有效组合起来，从而构筑一套既流畅又高效的运维工作流。
+
+## 示例
+
+### 场景说明
+
+“房间服无损发布” 需要满足以下特点：
+
+- 正在游戏的旧版本房间不受影响，而空闲的旧版本房间服需要被回收清理
+- 存在一定数量的新版本房间，可让新连接的玩家随时进入
+
+为在新版本发布保证“房间无损”，房间服在交付时会选择 OnDelete 更新策略，以实现存量房间不被删除，新创建的房间使用新的镜像的效果。此外，对应GameServerSet可以通过配置OKG自定义服务质量与自动伸缩策略实现自动化生命周期管理。有关房间服最佳实践文档可参考 https://openkruise.io/zh/kruisegame/best-practices/session-based-game
+
+### 新版发布流程
+
+基于以上交付内容，运维工程师在更新新版本时将进行以下动作：
+
+1. 更新GameServerSet镜像，此时正在运行的房间服不会删除或重建
+2. 对GameServerSet进行扩容，扩容出足够多的新版本房间服
+3. 确认新版本房间服的状态是否正常提供服务
+4. 清理旧版本的空闲房间
+
+接下来我们将通过一个示例展示如何一键式完成以上流程。
+
+### 模拟存量旧版本房间服状态
+
+*注：集群中需安装OKG*
+
+集群中有3个旧版本房间服，版本号为`1.12.2`
+
+```
+cat <<EOF | kubectl apply -f -
+apiVersion: game.kruise.io/v1alpha1
+kind: GameServerSet
+metadata:
+  name: minecraft
+  namespace: default
+spec:
+  replicas: 3
+  updateStrategy:
+    type: OnDelete
+  gameServerTemplate:
+    spec:
+      containers:
+        - image: registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2
+          name: minecraft
+EOF
+```
+
+其中，minecraft-0存在玩家
+
+```
+kubectl patch gs minecraft-0 --type=merge -p '{"spec":{"opsState":"Allocated"}}'
+```
+
+现状：
+
+```
+kubectl get gs
+NAME          STATE   OPSSTATE    DP    UP    AGE
+minecraft-0   Ready   Allocated   0     0     27s
+minecraft-1   Ready   None        0     0     27s
+minecraft-2   Ready   None        0     0     27s
+```
+
+### 通过Workflow进行新版本一键发布
+
+*注：集群中需要安装[Argo Workflow组件](https://argoproj.github.io/workflows/)*
+
+部署如下Yaml，执行 kubectl create -f workflow-demo.yaml
+
+```
+# workflow-demo.yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+  generateName: workflow-demo-
+  namespace: kruise-game-system
+spec:
+  serviceAccountName: kruise-game-controller-manager
+  entrypoint: main
+  templates:
+    - name: main
+      steps:
+        - - name: patch-image
+            template: patch-image
+        - - name: scale-replicas
+            template: scale-replicas
+        - - name: check-pods-ready
+            template: check-pods-ready
+        - - name: gs-update
+            template: gs-update
+    - name: patch-image
+      resource:
+        action: patch
+        mergeStrategy: merge
+        manifest: |
+          apiVersion: game.kruise.io/v1alpha1
+          kind: GameServerSet
+          metadata:
+            name: minecraft
+            namespace: default
+          spec:
+            gameServerTemplate:
+              spec:
+                containers:
+                - name: minecraft
+                  image: registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new
+    - name: scale-replicas
+      resource:
+        action: patch
+        mergeStrategy: merge
+        manifest: |
+          apiVersion: game.kruise.io/v1alpha1
+          kind: GameServerSet
+          metadata:
+            name: minecraft
+            namespace: default
+          spec:
+            replicas: 6
+    - name: check-pods-ready
+      retryStrategy:
+        retryPolicy: "OnError"
+        backoff:
+          duration: "10s"
+          factor: 2
+      script:
+        image: registry.cn-beijing.aliyuncs.com/chrisliu95/kubectl:latest
+        command: [bash]
+        source: |
+          #!/bin/bash
+
+          DESIRED_IMAGE="registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new"
+          LABEL_SELECTOR="game.kruise.io/owner-gss=minecraft"
+          DESIRED_READY_COUNT=3  # 你期望的就绪 Pod 的数量
+          NAMESPACE="default"  # 适当地更改名称空间
+
+          # 使用 kubectl 获取所有包含正确标签的 Pods
+          PODS_JSON=$(kubectl get pods -n ${NAMESPACE} -l ${LABEL_SELECTOR} -o json)
+
+          # 初始化就绪的 Pods 数量
+          COUNT_READY=0
+
+          # 根据提供的JSON信息来查找匹配的pods（以及它们的状态）
+          for pod in $(echo "$PODS_JSON" | jq -r '.items[] | select(.status.phase=="Running") | .metadata.name'); do
+            # 获取 Pod 的每个容器的镜像并检查是否 Pod 就绪
+            POD_IMAGES=$(echo "$PODS_JSON" | jq -r ".items[] | select(.metadata.name==\"$pod\") | .spec.containers[].image")
+            IS_READY=$(echo "$PODS_JSON" | jq -r ".items[] | select(.metadata.name==\"$pod\") | .status.conditions[] | select(.type==\"Ready\") | .status")
+
+            if [[ "$POD_IMAGES" == *"$DESIRED_IMAGE"* && "$IS_READY" == "True" ]]; then
+              COUNT_READY=$((COUNT_READY+1))
+            fi
+          done
+
+          # 输出就绪的 Pods 数量
+          echo "Ready Pods with image ${DESIRED_IMAGE}: ${COUNT_READY}"
+
+          # 比较实际就绪的 Pods 数量与期待数量
+          if [[ "${COUNT_READY}" -eq "${DESIRED_READY_COUNT}" ]]; then
+            echo "The number of ready Pods matches the desired count of ${DESIRED_READY_COUNT}."
+          else
+            echo "The number of ready Pods (${COUNT_READY}) does not match the desired count of ${DESIRED_READY_COUNT}."
+            exit 1
+          fi
+    - name: gs-update
+      container:
+        image: registry.cn-beijing.aliyuncs.com/chrisliu95/gs-updater:v1.2
+        command:
+          - /updater
+        args:
+          - --gss-name=minecraft
+          - --namespace=default
+          - --select-opsState=None
+          - --select-not-container-image=minecraft/registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new
+          - --exp-opsState=WaitToBeDeleted
+```
+
+该workflow包含了四个step，分别对应上述发布流程的四个步骤，涉及到三种类型的模版：
+
+- resource —— 对K8s对象进行操作。本例中step 1/2 对GameServerSet进行了patch操作，分别更新镜像版本为`1.12.2-new`、以及扩充了`3`个新版本房间。注意该workflow配置了service account以获取操作集群资源的相应权限，为了方便展示，此处直接使用了 kruise-game-system 命名空间下的 kruise-game-controller-manager 对应的sa。
+- script —— 启动容器执行自定义脚本。本例中 step 3 使用了带有kubectl命令行基础容器，以脚本的方式对新扩容出来的pod进行状态校验，确保Ready数量准确时再进入下一阶段。这里配置了重试策略：当执行失败（OnError）后会再次校验，间隔时长为10s，间隔时间延长的倍数为2。
+- container —— 启动一个容器执行相应参数命令。本例中 step 3 使用了 [GameServer-Updater](https://github.com/CloudNativeGame/GameServers-Updater) 工具，可以批量设置gs的状态。此时，将版本号不为1.12.2-new且opsState是None的房间服的opsState设置为WaitToBeDeleted。这样后续通过自动缩容，即可完成自动化旧版本清理。
+
+该workflow执行后，依次产生四个workflow pod。房间服新扩容出3、4、5号，且最终将空闲的1、2号的旧版本房间服设置为WaitToBeDeleted：
+
+```
+kubectl get workflow -n kruise-game-system
+NAME                  STATUS      AGE
+workflow-demo-cb56r   Running     8s
+
+kubectl get po -n kruise-game-system | grep workflow
+workflow-demo-cb56r-1053258062                    0/1     Completed   0          40s
+workflow-demo-cb56r-2754258264                    0/2     Completed   0          10s
+workflow-demo-cb56r-3772280549                    0/2     Completed   0          30s
+workflow-demo-cb56r-644543209                     0/1     Completed   0          61s
+
+kubectl get gs
+NAME          STATE   OPSSTATE          DP    UP    AGE
+minecraft-0   Ready   Allocated         0     0     2m18s
+minecraft-1   Ready   WaitToBeDeleted   0     0     2m18s
+minecraft-2   Ready   WaitToBeDeleted   0     0     2m18s
+minecraft-3   Ready   None              0     0     57s
+minecraft-4   Ready   None              0     0     57s
+minecraft-5   Ready   None              0     0     57s
+
+kubectl get workflow -n kruise-game-system
+NAME                  STATUS      AGE
+workflow-demo-cb56r   Succeeded   108s
+```
\ No newline at end of file
diff --git a/kruisegame/best-practices/workflow.md b/kruisegame/best-practices/workflow.md
new file mode 100644
index 000000000..baf10424b
--- /dev/null
+++ b/kruisegame/best-practices/workflow.md
@@ -0,0 +1,200 @@
+# Best Practices for Game O&M Workflow
+
+## Background
+Due to the stateful nature of game servers, for game operations, it often requires corresponding processing based on the current business state to avoid harming the player experience. OKG provides the capacity for game server state awareness and targeted management, with the prerequisite ability to handle differently according to different states. In actual production, an operation process is a combination of multiple operation actions, and operation engineers often need to perform the repetitive actions of "Game Server State Confirmation" → "Game Server Operation", which also leads to a certain level of operational complexity after the game servers become cloud-native.
+This article will combine the practical scenario of "Seamless Release of Room Services" to show readers how to effectively combine operations on GameServerSet and GameServer with Argo Workflow, thus building a smooth and efficient operation workflow.
+
+## Examples
+
+### Scenario Description
+
+"Seamless Release of Room Services" needs to meet the following characteristics:
+
+Old version rooms that are in-game are unaffected, while idle old version room services need to be recycled and cleaned up.
+Have a certain number of new version rooms available for new players to join at any time. To ensure "room seamless" in the new version release, room services will choose the OnDelete update strategy at the time of delivery, to achieve the effect that existing rooms are not deleted and newly created rooms use a new image. Additionally, the corresponding GameServerSet can achieve automated lifecycle management through configuration of OKG custom service quality and auto-scaling policies. Please refer to https://openkruise.io/kruisegame/best-practices/session-based-game for the best practice document on room services.
+
+### New Version Release Process
+
+Based on the above delivery content, operation engineers will perform the following actions when updating a new version:
+
+1. Update the GameServerSet image; at this time, the room services that are running will not be deleted or rebuilt.
+2. Expand the GameServerSet to generate enough new version room services.
+3. Confirm whether the new version room services are in a normal service state.
+4. Clear idle old version rooms. Next, we will show through an example how to complete the above process with one click.
+
+### Simulate the State of the Legacy Old Version Room Service
+
+_Note: OKG must be installed in the cluster._
+
+There are 3 old version room services in the cluster, with image tag 1.12.2.
+
+```
+cat <<EOF | kubectl apply -f -
+apiVersion: game.kruise.io/v1alpha1
+kind: GameServerSet
+metadata:
+  name: minecraft
+  namespace: default
+spec:
+  replicas: 3
+  updateStrategy:
+    type: OnDelete
+  gameServerTemplate:
+    spec:
+      containers:
+        - image: registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2
+          name: minecraft
+EOF
+```
+Among them, minecraft-0 has players.
+
+```
+kubectl patch gs minecraft-0 --type=merge -p '{"spec":{"opsState":"Allocated"}}'
+```
+
+Current status:
+
+```
+kubectl get gs
+NAME          STATE   OPSSTATE    DP    UP    AGE
+minecraft-0   Ready   Allocated   0     0     27s
+minecraft-1   Ready   None        0     0     27s
+minecraft-2   Ready   None        0     0     27s
+```
+
+### One-Click Release of New Version Through Workflow
+
+_Note: [Argo Workflow component](https://argoproj.github.io/argo-workflows/) must be installed in the cluster._
+
+Deploy the following Yaml, and execute kubectl create -f workflow-demo.yaml.
+```
+# workflow-demo.yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+  generateName: workflow-demo-
+  namespace: kruise-game-system
+spec:
+  serviceAccountName: kruise-game-controller-manager
+  entrypoint: main
+  templates:
+    - name: main
+      steps:
+        - - name: patch-image
+            template: patch-image
+        - - name: scale-replicas
+            template: scale-replicas
+        - - name: check-pods-ready
+            template: check-pods-ready
+        - - name: gs-update
+            template: gs-update
+    - name: patch-image
+      resource:
+        action: patch
+        mergeStrategy: merge
+        manifest: |
+          apiVersion: game.kruise.io/v1alpha1
+          kind: GameServerSet
+          metadata:
+            name: minecraft
+            namespace: default
+          spec:
+            gameServerTemplate:
+              spec:
+                containers:
+                - name: minecraft
+                  image: registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new
+    - name: scale-replicas
+      resource:
+        action: patch
+        mergeStrategy: merge
+        manifest: |
+          apiVersion: game.kruise.io/v1alpha1
+          kind: GameServerSet
+          metadata:
+            name: minecraft
+            namespace: default
+          spec:
+            replicas: 6
+    - name: check-pods-ready
+      retryStrategy:
+        retryPolicy: "OnError"
+        backoff:
+          duration: "10s"
+          factor: 2
+      script:
+        image: registry.cn-beijing.aliyuncs.com/chrisliu95/kubectl:latest
+        command: [bash]
+        source: |
+          #!/bin/bash
+          DESIRED_IMAGE="registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new"
+          LABEL_SELECTOR="game.kruise.io/owner-gss=minecraft"
+          DESIRED_READY_COUNT=3  # The desired count of ready Pods
+          NAMESPACE="default"  # Modify the namespace appropriately
+          # Use kubectl to get all Pods with the correct labels
+          PODS_JSON=$(kubectl get pods -n ${NAMESPACE} -l ${LABEL_SELECTOR} -o json)
+          # Initialize the count of ready Pods
+          COUNT_READY=0
+          # Use the provided JSON information to find matching pods (and their status)
+          for pod in $(echo "$PODS_JSON" | jq -r '.items[] | select(.status.phase=="Running") | .metadata.name'); do
+            # Get the image of each container in the Pod and check if the Pod is ready
+            POD_IMAGES=$(echo "$PODS_JSON" | jq -r ".items[] | select(.metadata.name==\"$pod\") | .spec.containers[].image")
+            IS_READY=$(echo "$PODS_JSON" | jq -r ".items[] | select(.metadata.name==\"$pod\") | .status.conditions[] | select(.type==\"Ready\") | .status")
+            if [[ "$POD_IMAGES" == *"$DESIRED_IMAGE"* && "$IS_READY" == "True" ]]; then
+              COUNT_READY=$((COUNT_READY+1))
+            fi
+          done
+          # Output the count of ready Pods
+          echo "Ready Pods with image ${DESIRED_IMAGE}: ${COUNT_READY}"
+          # Compare the actual count of ready Pods with the desired count
+          if [[ "${COUNT_READY}" -eq "${DESIRED_READY_COUNT}" ]]; then
+            echo "The number of ready Pods matches the desired count of ${DESIRED_READY_COUNT}."
+          else
+            echo "The number of ready Pods (${COUNT_READY}) does not match the desired count of ${DESIRED_READY_COUNT}."
+            exit 1
+          fi
+    - name: gs-update
+      container:
+        image: registry.cn-beijing.aliyuncs.com/chrisliu95/gs-updater:v1.2
+        command:
+          - /updater
+        args:
+          - --gss-name=minecraft
+          - --namespace=default
+          - --select-opsState=None
+          - --select-not-container-image=minecraft/registry.cn-hangzhou.aliyuncs.com/acs/minecraft-demo:1.12.2-new
+          - --exp-opsState=WaitToBeDeleted
+```
+
+The workflow contains four steps, corresponding to the four steps of the release process mentioned earlier, involving three types of templates:
+
+- resource — Performs operations on K8s objects. In this case, step 1/2 performs a patch operation on the GameServerSet, respectively updating the image version to 1.12.2-new and expanding the service with 3 new version rooms. Note that this workflow is configured with a service account to obtain the necessary permissions to operate cluster resources. For demonstration ease, the service account kruise-game-controller-manager under the kruise-game-system namespace is used.
+- script — Launches a container to execute a custom script. In this case, step 3 uses a base container with the kubectl command line to check the status of the newly expanded pods in script form, ensuring accurate Ready numbers before proceeding to the next phase. Here a retry strategy is configured: if execution fails (OnError), it will be verified again with a 10s interval, where the interval duration multiplies by 2.
+- container — Launches a container with the corresponding parameters to execute commands. In this case, step 3 uses the [GameServer-Updater](https://github.com/CloudNativeGame/GameServers-Updater) tool, which can batch set the status of gs. At this point, the opsState of the room service, whose version number is not 1.12.2-new and opsState is None, is set to WaitToBeDeleted. This way, subsequent automatic shrinkage can automatically complete the cleanup of the old versions. 
+
+After the workflow execution, four workflow pods will be sequentially created. Room services with numbers 3, 4, and 5 are newly expanded, and the idle old version room services numbered 1 and 2 are set to WaitToBeDeleted:
+```
+kubectl get workflow -n kruise-game-system
+NAME                  STATUS      AGE
+workflow-demo-cb56r   Running     8s
+
+kubectl get po -n kruise-game-system | grep workflow
+workflow-demo-cb56r-1053258062                    0/1     Completed   0          40s
+workflow-demo-cb56r-2754258264                    0/2     Completed   0          10s
+workflow-demo-cb56r-3772280549                    0/2     Completed   0          30s
+workflow-demo-cb56r-644543209                     0/1     Completed   0          61s
+
+kubectl get gs
+NAME          STATE   OPSSTATE          DP    UP    AGE
+minecraft-0   Ready   Allocated         0     0     2m18s
+minecraft-1   Ready   WaitToBeDeleted   0     0     2m18s
+minecraft-2   Ready   WaitToBeDeleted   0     0     2m18s
+minecraft-3   Ready   None              0     0     57s
+minecraft-4   Ready   None              0     0     57s
+minecraft-5   Ready   None              0     0     57s
+
+kubectl get workflow -n kruise-game-system
+NAME                  STATUS      AGE
+workflow-demo-cb56r   Succeeded   108s
+```
+
diff --git a/sidebars-kruisegame.js b/sidebars-kruisegame.js
index a8e108db7..cd42dd233 100644
--- a/sidebars-kruisegame.js
+++ b/sidebars-kruisegame.js
@@ -47,7 +47,8 @@ module.exports = {
                 'best-practices/session-based-game',
                 'best-practices/pve-game',
                 'best-practices/shared-mem',
-                'best-practices/gameserver-delivery-management'
+                'best-practices/gameserver-delivery-management',
+                'best-practices/workflow'
             ],
         },
         {