版本发布、配置与研发管线

Category

production 树总览。覆盖：版本体系（01–02）、发布安全（03）、发布协同（04）、配置管线（05）、发布工作流（06）、工作室方法（07），以及 config 子树（config/01–04）与 retro 子树（retro/01–05）。

Definition

版本问题在游戏项目里从来不只是“把包打出来然后上线”。真正麻烦的地方在于，客户端、资源、脚本、配置、协议、服务端逻辑和活动数据往往以不同节奏变化，但玩家、渠道审核、平台规则、线上活动和多端共存又逼着这些变化同时被系统承接。发布体系因此不只是一个操作流程，而是一整套长期治理能力。

很多团队在版本问题上吃亏，不是因为不会发版，而是因为长期把它理解得太窄：

• 以为线上只有一个“当前版本”
• 以为有 CI/CD 就等于有版本治理
• 以为灰度只是百分比开关
• 以为配置表和活动数据不算正式发布链路

真实世界里，发布稳定性来自更底层的能力：系统能不能描述当前玩家到底运行着哪一组构件，这组构件之间是否兼容，问题出现时能不能缩小影响面、快速止损并回到稳定状态。

这一章讨论的不是某次提审和上线步骤，而是版本作为一套长期存在的工程对象，应该怎样被拆开、被约束、被观测和被协同。

Related

关系链：版本拆分（01–02）→ 发布安全（03）→ 协同（04）→ 配置管线（05 与 config 子树）→ 工作流（06）；选型与复盘的方法论收束在 retro 子树。上游：client 树（客户端构件的生产端）；下游：operation 树（运营与观察）、numerical 树（数值配置侧）。

Reference

节点清单见下节。

本章文章

• 版本体系总览：先建立“版本不是一个数字，而是一组相关构件”的整体视角。
• 客户端、资源、配置与协议版本：把不同版本维度拆开看，说明为什么它们不能长期绑成一个节奏。
• 灰度、回滚与兼容窗口：讨论发布安全真正依赖的三种能力，以及它们为什么必须一起存在。
• 前后端协同与平台约束：分析平台审核、渠道规则、SDK 和多端协同为什么会反向塑造发布方案。
• 配置表与数据驱动管线：把配置视作正式发布对象，而不是附属编辑产物。
• 研发协作与发布工作流：解释为什么版本稳定性最终仍然会回到组织边界、责任界面和工作流设计上。
• 工作室分工与质量门禁：把成熟工作室的角色分层、阶段门禁与质量证据收成可裁剪的参考结构。