折腾《薄雾/迷雾》官网更新日志这事儿，我真是被搞怕了
别看一个游戏官网的“更新日志”模块好像挺简单，不就是把补丁内容写上去嘛我跟你说，这玩意儿能把我气得半死。这背后牵扯到的部门扯皮、版本混乱、深夜被叫起来救火的事，外人根本不知道。
从零开始：谁来写，怎么写？
项目刚启动那会儿，我们都没把更新日志当回事。最初的想法特别蠢，就是让开发团队自己写个文本文件，然后丢给前端，前端直接贴上去。我当时就觉得这不行，但架不住人力少，先这么凑合着。
第一次实践：直接复制粘贴。
- 开发那边拉一个Git Commit记录。
- 运营或者翻译组在上面修修补补，把技术黑话变成人话。
- 把排版弄丢给前端。
你猜怎么着？每次更新都是一场灾难。我们这个《薄雾/迷雾》游戏，更新频率又高，几乎周周都有小补丁。每次前端都要手动调格式，多国语言版本一多，大家对着Word文档改来改去，一团乱麻。有一次，一个重要的平衡性调整，中文版写了，英文版忘了，玩家直接在论坛骂翻了天，说我们偏心。
第二次大改：引入CMS系统
被骂怕了，老板决定要搞一个正规的系统。我说行，我们干脆上一个轻量级的CMS（内容管理系统），把更新日志变成一个可以结构化发布的东西。
我当时的想法很简单：
第一步，规划字段。 我拉着运营和翻译团队，把日志需要的内容全列出来：
- 版本号
- 发布日期
- 语言类型（中文、英文、日文等）
- 内容本体（用Markdown写，方便排版）
- 类型标签（比如“平衡调整”、“Bug修复”、“新增内容”）
第二步，动手实现。 我找了个开源的Headless CMS，自己搭了个服务。这下子，运营组可以在界面上直接编辑，翻译组也能在后台直接处理多语言版本，看起来效率高多了。
但新的问题马上就来了：权限和版本回滚。
CMS虽然能发内容，但它跟我们游戏服务器的版本控制是脱钩的。有一次，QA那边发现一个大Bug，赶紧叫停了版本发布，结果运营组的人手快，日志已经发出去了。我半夜两点被电话叫醒，迷迷糊糊爬起来，发现CMS的界面里没有“立刻回滚到草稿”的按钮，只能手动去数据库里把那条数据删掉，再给官网做一次热更新，折腾到早上四点。
为什么我半夜三更在搞这个破事？
这件事发生的时候，我正在备考一个重要的证书，每天晚上十点就睡了，早上五点爬起来看书。那次半夜被叫起来，我火气特别大。我当时就想，我们花了这么大力气搭的系统，为什么还是这么脆弱？
我仔细一琢磨，问题根本不是出在CMS选得好不而是出在流程设计上。
开发团队、QA团队、运营团队，这三方是割裂的。开发那边打包好了，QA测完了，通知运营“可以发了”。但如果QA临时叫停，这个通知链条就会断掉，日志发布就可能失控。说白了，大家都是各自为战，信息传达全靠吼和发微信。
而且那段时间，公司内部管理特别混乱。我的直属上司换了人，新上司又不懂技术，整天就盯着各种报表，天天催着我要“数据好看”，根本不关心我们这些一线开发人员是怎么被流程卡死的。
那次连夜救火把我身体搞垮了，高烧两天，直接把考试也耽误了。我当时就做了一个决定：与其等着流程规范，不如从技术上直接锁死，让日志的发布必须依赖于游戏的实际版本。
最终拍板：日志即代码
我把整个CMS系统推翻了。没错，全推翻了。既然大家各自为战，那我就把控制权收到自己手里。
第三次实践：日志即代码（Log-as-Code）。
我最终的方案很简单粗暴：
所有的更新日志，现在都以Markdown文件的形式，直接存放在游戏代码仓库的一个特定目录下。只有当版本被打包并被QA认证通过后，这个特定的日志文件才会带着它的版本号，被自动推送到一个简单的Web Hook接口。
这有什么好处？
- 绝对同步：如果版本没过QA，这个日志文件就压根不会被推到官网上，杜绝了误发的可能。
- 版本控制：因为日志文件在Git里，每次修改都有记录，回滚也变得超级简单，直接回滚代码库的版本就行了。
- 减轻前端负担：官网前端只需要通过API拉取最新的Markdown文本，直接渲染。
这套东西跑起来之后，所有人都轻松了。运营那边一开始还抱怨说没有漂亮的编辑界面了，但用了一段时间发现，只要写好Markdown，剩下的排版和多语言切换都是系统自动完成的，再也不用担心半夜被叫起来删库了。这个日志系统，才算是真正稳定下来，跟着《薄雾/迷雾》的版本节奏跑起来了。现在回想起来，为了这么个小小的功能，竟然折腾了三个月，真是让人哭笑不得。