加载中…【用户文章转载】版本管理这件事，没有偏执，惟有极致
(2022-06-16 13:29:39)
标签：
helixcoreperforce |
分类： 龙智和Perforce最新动态 |
本文作者向华是资深游戏开发工程师，拥有8年游戏测试开发经验。他是前原神项目P4
Admin，也是一名持续集成开发者。作为Perforce
Helix
Core的用户，他结合自身项目实践经验，带来关于VCS迁移、发布版本的提交控制以及P4工具链的采用原则等干货。立即联系Perforce授权合作伙伴——龙智，获得更多关于Perforce
Helix Core的咨询、试用、服务等信息。
就在上个月，巨忙，项目上线了。有幸参与了项目的一部分版本管理工作，诸多总结和反思，遴选后与君分享。关于 VCS 迁移项目起初是用 Git 做版本控制的。后来发现了以下几个问题：
就在上个月，巨忙，项目上线了。有幸参与了项目的一部分版本管理工作，诸多总结和反思，遴选后与君分享。关于 VCS 迁移项目起初是用 Git 做版本控制的。后来发现了以下几个问题：
- 单文件/目录版本回滚（rollback）艰难。
- 策划数据经常被冲表。
- 分支满天飞，合并不可控。
在修缮过渡期，我们做了一个 Git 的 Commit Hook 脚本，持续性地将Git 的提交记录 Submit 到 P4 仓库。
显而易见，这种做法损失了过往的 Git 提交日志和不同分支间文件合并记录。权衡之后，项目组接受了此方案。最终用了 2 周时间，项目成功迁移至 P4 工作流。
通过 P4 Protection 的权限控制，将分支写入权限关闭，只将写入权限开放给固定的白名单组，谁提交谁进白名单组。
这个方案是早些年从网易游戏习得的，当时的前辈们集大成地将此方案追求极致，现已有非常成熟的工具链。周版本的不断迭代，最终进化为线上发布版本，每一次迭代都是通向成功上线的台阶，我们每个人都很重视。好在每个版本我们都按时完成交付。关于P4工具链
在原神，曾和项目的其他伙伴们完成了 10+ 个工具链。而在现在的小团队，工具链的制作思路并不一定适合。制作一套支撑项目运行的完备工具链，需要耗费大量心力和团队的力量，在有限的软硬件资源下，我们只能选择与上线相关且必要的。另外，这里有强大的中台团队作为支撑，很多基础设施直接能够复用，着实省了很多事。而自己根据项目的特点，特殊修改和挂接了一些符合项目特点的小脚本，也能让效率得到不少提升。总结一下，我们工具链制作采用的原则就是：- 选择必要，业务必需的加上；
- 复用现有，关注成本，快、稳是第一要务；
- 因地制宜，小范围的调整也能有不错的效果。
写在最后
每一段上线的旅程，都是一场博弈。整体下来，仍有太多不甚完美的地方，需要继续加强与各大专业团队的 CI 工具链同仁们交流。感谢阅读。如需免费试用Perforce Helix Core，请立即联系Perforce授权合作伙伴——龙智：
电话：400-775-5506
邮箱：marketing@shdsd.com
喜欢
0
赠金笔