AAA老兵关于建立可拓展DevOps工具链的建议

Monster Closet Games工作室虽小，但他们怀揣着大梦想，以及与之相配的经验。大部分核心团队有20年以上的从业经验，部分参与过大型游戏系列的开发，从《刺客信条》和《波斯王子》到《孤岛惊魂》和《光环》。目前，团队正在开发一款代号为“Project Shrine”的在线多人游戏，并计划发布到PC和次世代主机。

“概括地说，这是款第三人称合作地下城突袭游戏，”Monster Closet的CEO格雷姆·詹尼斯（Graeme Jennings）表示，“你需要和团队一起建立默契，探查地下城里的财宝。团队的合作是中心。”

团队协作是Monster Closet开发游戏的核心方法，工作室一直联系紧密、工作专心。“我更喜欢有40-50名能愉快合作、认可我们的工作方式、并能打造出超棒游戏的开发者，”詹尼斯说，“我真心认为优秀的团队配上正确的工具能制作出高品质的游戏。”

Monster Closet的艺术家和开发者们非常熟悉强大的专利性技术栈，从零建立自己的技术栈意味着抛弃原有的方案，于是在头几个月，团队小心组建了一条可扩展的工具链。

在“Project Shrine”里，Monster Closet使用了Unity独立于引擎的DevOps方案和自动化来加快生产，包括用于源控制的Unity Version Control和用于错误跟踪的Backtrace。我们采访了Monster Closet的首席在线程序员派翠丝·博伟（Patrice Beauvais），以及CTO托马斯·菲力克斯（Thomas Félix）来了解他们正在创作的内容，以及怎样打造一种便于扩展的技术栈。

您在建立技术栈的时候会考虑哪些因素？

托马斯：我们几人有完全不同的在线游戏开发经历，且我们需要一种支持长远发展、稳固的DevOps基础。即便GAAS（游戏即服务）不是游戏的核心，我们还是想要一种能帮我们快速发布、迭代的强大技术栈。

我们都用过Perforce，但是不太喜欢——它用起来挺好，不过我们经常那它做些自身用途以外的事。我们还看过Git，可最后发现了Unity Version Control。

从书面上看，Unity Version Control混合了类似Git的方法，同时还用Perforce这类更强大的方案来管理数据。我们还受到Unity Version Control的任务分支吸引；经过六个月的评估后，我们决定试一试。彼时，团队有六到七个人。我们团队增长缓慢，工具的扩展也非常缓和。目前我们有大约43人，方案迄今的表现都很不错。

你们测试版本控制系统的流程是怎样的？

派翠斯：从技术人员的角度来说，我们不想把项目一半存在Git上，一半存在Perforce上。我们清楚同时使用和维护两种源码管理工具非常累人——而许多在线游戏的线上系统和游戏数据并不一定就在一处。

而且团队的规模也限制了你们采取类似方法——Unity Version Control对两种流程的辅助作用有帮到你们吗？

派翠斯：当然了。

你们此前使用两种版本控制系统时遇到过哪些问题？

托马斯：在开发游戏时，你肯定得定制下工具，无论工具本身有多好。拿Unity Version Control为例——尽管它很好，我们还是得根据工作流定制。要是得支持两个源控制系统，工作量就得翻倍，造成身心上的痛苦。能用Git的人不一定熟悉Perforce，反过来也是。所以员工培训也得花两倍时间。

派翠斯：对我来说，整合两个系统的数据是最难受的。如果数据库存在了Git上，数据就得回到Perforce，两个系统需要建立起一种交换机制。尽管有许多现成方案，但系统间的交互并非其设计意图，项目历史有时都会丢失。大型团队可以解决这个问题，但我可没有余力花六个月单单建立一个从Git到Perforce转移数据的方案。

听起来你们多年来用过许多不同的版本控制系统。这些方案都有哪些强项和缺点呢？

托马斯：先说说Perforce——它非常耐用，能很好地管理数据，对非技术人员来说也不是很复杂。这些优点可能只此一家，除开Unity Version Control。另一方面，“monorepo”不太适用于游戏开发——即整合快、分支多等等。Perforce可以用来管理项目，但它原算不上理想的选择，尤其是在建立一条稳固的CI/CD管线时。

派翠斯：Git的UI对程序员来说很棒，但我不会强迫一名艺术家来使用它。工具不适合用来管理大型文件和数据，并且迄今尚未原生支持锁定。

托马斯：Unity Version Control从许多方面来说都更好——UI专为内容创作者制定，可用性强。我们觉得Unity Version Control是Git和Perforce的完美结合。

程序员通常爱用Git，Unity Version Control提供有近乎一样的工作流。而不懂技术的创作者可以轻松提交数据，化解源控制里最为棘手的一个问题。

这里能出现的最坏情况可能就是数据丢失。每个源控制方案都能轻松处理代码，但数据管理起来就没那么容易了。丢失数据事关重大，数据上的每处错误都会在随后耗费上千倍的成本。我们对此是小心再小心。而Unity Version Control对于程序员和内容创作者来说是“双赢”。

您有推荐的维持版本完整性的最佳方法吗？

托马斯：对于我们这种小公司，我们一开始就知道提交损坏数据或代码到主干，造成版本损坏的后果是非常沉重的。

有了Unity Version Control，所有工作都不会在主干上发生。我们时刻掌控着主干，主干一直非常稳定，而合并机器人（mergebot）能代为完成大部分工作。这一点深深地引起了我们的共鸣，并且也成为了我们首要考虑因素，即便当时我们只有五个人在管理主版本。它的效果非常好：主干几乎没有下线过，这都快持续两年了。

Unity Version Control在处理大型文件、切换分支与工作空间上的速度如何？

托马斯：说到任务分支和来回切换，这部分也很好用。这种工作流熟悉起来要花些时间——许多人从未接触过任务分支的概念，艺术家和程序员刚开始可能没法运用自如。

尽管如此，我们每周（不是每天）都会在合并机器人和CI/CD管线发现一些小问题，但问题从来不会进入主干或破坏版本。这熟悉起来要点时间，不过编辑一条分支总要比两条来得快——快得不多，但如果把管线看作一个整体，这种工作方式就要显得好的多得多。至少对我们这种中小型公司，它很完美。

切换到连贯部署需要你改变自己的文化和经验，但你可以肯定自己能在bug和潜在问题再度出现前就捕捉到它们。

托马斯：说得对。我是不会回到单条主干的开发里了。我们团队没有雨里花数天调试或修补反复出现的问题。

在采访Apocalypse Studios期间，他们讨论了任务分支所带来的“文化切换”。他们在用Unity Version Control前也用的Perforce，并且对比过分支与开发流。对此，你们是怎么看的？

托马斯：分支和流水线对我来说很不一样。如果没有Unity Version Control，我们可能会围绕流水线制定一套方案，实现相同的效果，但这套方案可能非常复杂、容易出错。在Unity Version Control里，分支非常简单、安全，因为它正是为这种工作流打造的。

在Perforce里，流水线相当于任务。特别熟悉技术的人可以驾轻就熟，但我不会让艺术人员也使用它。有了Unity Version Control，我们目前创建了1000条分支——大部分已经被归档，并且经常有10-15条活跃的分支。在Perforce里创建1000条项目分支好像并不那么现实。

随着开发推进，你们预想了哪些挑战？已经面对过哪些？

派翠斯：前边提到，大家并不能立即熟悉分支的工作方式。艺术家们更是从未接触过类似的东西，所以我们仔细地解释了使用方法和背后原因。

托马斯：没错，大家并不是说抗拒，而是要切换自己的工作文化。如果要像我们一样切换到Unity Version Control，就必须考虑到这点。这种工作方式更好，但要求你跳出框框思考。我们一开始几乎什么都没有——没有办公室、基础设施，团队也小——所以我们转变起来可能比其他工作室要轻松点。在云端建立基础设施听起来很酷，但它也会带来迭代时间、成本、安装、安全等等一系列挑战。最终的结果是好的，但我们还是花了些时间来建立并运行起一条可靠的工作流。

你们还在使用另一款无视引擎的Unity解决方案：Backtrace。能介绍下你们跟踪错误的管线是什么样的吗？

托马斯：我们用Backtrace来跟踪几乎每一个应用bug——首当其冲的当然就是游戏和编辑器了。前边提到我们围绕Unity Version Control创建了几款工具——Backtrace也被整合到了里头。

它安装快捷，并且还包含顶级的工具、仪表盘和工作流。我们可以轻松地运用起在上家公司所用到的东西。在运作近六个月后，我们已经能看到游戏、编辑器和工具的每一次崩溃。实话说，我在创办工作室时没想过这么快就能用上这些东西。

派翠斯：工具真的超级棒。我曾在育碧用过两三年类似Backtrace的方案。Backtrace的功能很有前瞻性——它甚至要比育碧的更快，应用起来也很轻松。当然，我们定制了工具来捕捉特定数据，并且把它整合到了Linux服务器上。

托马斯：Backtrace的安装耗时给我们留下了深刻印象。只需两到三天我们就能收取崩溃报告，因此决定进一步使用它。

你们如何保证Unity Version Control的实施过程流畅顺滑？

我们发售过很多大型游戏，希望在新环境下套用以往的经验。因此我们最终选择了Unity Version Control以及Backtrace。最难的地方在于不要制造从未见过的问题——我们已经不是一个1000人的工作室了！

我们既希望利用过往经验，又得提醒自己手头的游戏并不是一款AAA大作。当然，我们还是想做些特别棒的东西，因此需要最好的工作流——Unity Version Control就是完美的选择。

你们测试这款版本控制系统的流程是？

托马斯：最难的部分在于为艺术人员改编UX和数据完整性。我们与团队的几名艺术家紧密沟通来保证他们能理解工具的使用。项目的数据管理非常重要。团队成员越多，反馈就越多——大家用的开心，我们就知道自己走在了正确的路上。

你们如何让艺术家使用Unity Version Control的Gluon工作流？

托马斯：我们的确用到了Gluon，但用在了另一种称为原始数据的东西上——即不与引擎捆绑的数据。比方说一名艺术家在创建一片网格模型：作为原始数据的模型源文件存在Blender等软件里。这些文件不会进入引擎，只有导出的模型会。此类数据托管于任务分支上，我们则用Gluon管理源文件。

此种文件可以变得非常大——角色美术用Zbrush生成的每个资产文件可以达到2、3、4 GB那么大，甚至更多。程序员没法把1 TB大小的原始角色网格模型同步到系统上，因此我们使用了Gluon的部分工作空间来管理这些文件。角色美术只需要同步角色文件，建模师只需要同步模型文件，音频、纹理等文件也是一样的。它们都存在另一条独立于任务分支的仓库中。

那总结起来，你们只在处理大型文件时使用Gluon，这样别人就不必下载整个仓库——只用一部分存储空间就行。

托马斯：正是。这些都是归档后的原始数据，我们不用专门创建任务分支。不必为材质创建分支，只要创作者能经常上传自己的作品即可。

如果有小型工作室也希望像你们一样扩大规模、开发更宏大的项目，您有什么建议吗？

托马斯：这是个好问题。从第一天起，你就必须明确目标。我们一开始是个小团队，扩充团队是预想之中的，但从未想过要成长为1000人的大团队——200人都有点多。我们据此做出了一些大家都满意的决定，如果目标不同，我们会做出完全不同的决定。

在云端建立基础设施确实能方便扩展，但小心它产生的高额成本。时刻掌控你的工作流。如果有东西没法工作，亲手尝试下来找出原因。保证自己从根本上有着稳固的根基。

想要优化您的游戏开发流程？那就来试试兼容所有引擎的Unity DevOps吧。