本文作者向华是资深游戏开发工程师，拥有 8 年游戏测试开发经验。他是前原神项目 P4 Admin，也是一名持续集成开发者。

作为Perforce Helix Core的用户，他结合自身项目实践经验，带来关于 VCS 迁移、发布版本的提交控制以及 P4 工具链的采用原则等干货。

立即联系Perforce授权合作伙伴——龙智，获得更多关于Perforce Helix Core的咨询、试用、服务等信息。

就在上个月，巨忙，项目上线了。

有幸参与了项目的一部分版本管理工作，诸多总结和反思，遴选后与君分享。

关于 VCS 迁移

项目起初是用 Git 做版本控制的。后来发现了以下几个问题：

• 单文件/目录版本回滚（rollback）艰难。

• 策划数据经常被冲表。

• 分支满天飞，合并不可控。

于是，与项目组同事一起，决定改造 VCS 工作流，做了一次从 Git 到 P4 的迁移。

这次迁移属于修缮者模式，也就是说 Git 还能用，逐步将策划数据仓库、客户端仓库、服务端仓库迁移至 P4，最终完成全迁。

过程不再赘述，可有一点不得不提，Perforce 在从 Git 迁移到 P4 的过程中似乎尚无一个完备的无损方案。

市面上能够搜索到的 git-p4（https://git-scm.com/docs/git-p4），还有官方提供的 Helix4Git，都是 Git 与 Perforce 共存的方案。

而我们想要的是全面迁移至 P4。

在修缮过渡期，我们做了一个 Git 的 Commit Hook 脚本，持续性地将 Git 的提交记录 Submit 到 P4 仓库。

显而易见，这种做法损失了过往的 Git 提交日志和不同分支间文件合并记录。

权衡之后，项目组接受了此方案。

最终用了 2 周时间，项目成功迁移至 P4 工作流。

 关于发布版本的提交控制

我不记得是听哪位大佬讲过，只有国内的游戏团队才有周版本制度。

项目起初是双周版本，开发节奏缓慢。借用一次 CE 测试的契机，推动项目切换为单周版本，加快了开发节奏，迎接项目组首次内测曝光。

与各大游戏公司的周版本模式类似，我们给团队成员提出要求，周版本构建出最终稳定包体后，才可以集体下班。

版本节奏的调整还是蛮有压力的，不论是来源于团队成员的看法，还是工作内容的爆炸式膨胀。

好在，大家同舟共济，渡过了这片时间沼泽。

感谢团队中所有在关键时刻能够挺身而出的同事。

对于周版本，甚至后来的线上版本，我们采用了通常的锁版本提交策略。

通过 P4 Protection 的权限控制，将分支写入权限关闭，只将写入权限开放给固定的白名单组，谁提交谁进白名单组。

这个方案是早些年从网易游戏习得的，当时的前辈们集大成地将此方案追求极致，现已有非常成熟的工具链。

周版本的不断迭代，最终进化为线上发布版本，每一次迭代都是通向成功上线的台阶，我们每个人都很重视。好在每个版本我们都按时完成交付。

关于 P4 工具链

在原神，曾和项目的其他伙伴们完成了 10+ 个工具链。

而在现在的小团队，工具链的制作思路并不一定适合。

制作一套支撑项目运行的完备工具链，需要耗费大量心力和团队的力量，在有限的软硬件资源下，我们只能选择与上线相关且必要的。

另外，这里有强大的中台团队作为支撑，很多基础设施直接能够复用，着实省了很多事。

而自己根据项目的特点，特殊修改和挂接了一些符合项目特点的小脚本，也能让效率得到不少提升。

总结一下，我们工具链制作采用的原则就是：

• 选择必要，业务必需的加上；

• 复用现有，关注成本，快、稳是第一要务；

• 因地制宜，小范围的调整也能有不错的效果。

写在最后

每一段上线的旅程，都是一场博弈。

整体下来，仍有太多不甚完美的地方，需要继续加强与各大专业团队的 CI 工具链同仁们交流。

感谢阅读。

如需免费试用 Perforce Helix Core，请立即联系Perforce授权合作伙伴——龙智：

电话：400-775-5506

邮箱：marketing@shdsd.com

邮箱：marketing@shdsd.com

邮箱：marketing@shdsd.com