共计 1429 个字符，预计需要花费 4 分钟才能阅读完成。
本文作者向华是资深游戏开发工程师，领有 8 年游戏测试开发教训。他是前原神我的项目 P4 Admin，也是一名继续集成开发者。
作为 Perforce Helix Core 的用户，他联合本身我的项目实践经验，带来对于 VCS 迁徙、公布版本的提交管制以及 P4 工具链的采纳准则等干货。
就在上个月，巨忙，我的项目上线了。
有幸参加了我的项目的一部分版本管理工作，诸多总结和反思，遴选后与君分享。
对于 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 工具链同仁们交换。
感激浏览。
