腾讯中台Rui Su：CROS行云，如何帮助超100款游戏提升研发效率

【GameLook专稿，未经授权不得转载！】

GameLook报道/如何将团队使用的各种工具逐步集成到研发管线和流程当中，是每一个研发团队在不同阶段都关心的问题。腾讯游戏的共同研发与运营系统（CROS）通过其专门用于游戏研发的一站式解决方案“Cloudflow Pipeline”，帮助超过100款游戏有效提升了研发效率。

在GDC 2023演讲中，来自腾讯游戏的CROS高级SRE经理Rui “Ryan” Su介绍了Cloudflow Pipeline是如何在研发过程中帮助数千名开发者提升了沟通和研发效率，包括产品要求管理、内容研发、版本管理、QA和发布流程，从而大幅缩短了代码交付周期。

以下是Gamelook听译的完整内容：

Rui Su：

今天我要说的是行云管线（CloudFlow Pipeline），本质上说，它是腾讯的一个build生态系统。

做一个简短介绍，我的名字是Rui或者Ryan，是腾讯全球技术服务中心的一名工程主管，从游戏角度我个人非常喜欢玩《魔兽世界》，到现在还在玩。

介绍一些CROS的情况，你们可能发现，腾讯、IEG或者腾讯游戏都非常庞大，CROS本质上是一个中心化技术服务团队，这些就是我们的能力。我们聚焦于开发者效率提升、我们在线游戏的技术运营，很明显，还包括QA。游戏安全，没有人希望被黑；商业价值附加，主要是游戏内的活动。最后，还有一个巨大的玩家平台组织，处理并赋能我们所有游戏。

整个CROS团队有2000人规模，我们为甲乙方工作室提供工业级游戏制作能力。接下来几分钟我要说的是，“一个人走的更快，一群人走的更远”，这就是CROS的故事。

快速说一下CROS带来的优势，其中一个就是很大程度上降低了服务期延迟，从每天的1.5小时降低到即时，将编译时间从4小时降低到2.5小时，客户端更新时间也几乎是即时的。另外，在debug和QA方面，发现bug的时间不再是需要两个半小时，而是变成了即时。

有一个比较出名的故事，上海工作室的一名工程师发现了一个bug，然后告诉深圳工作室的人，并且问是否需要他帮忙解决，但后者反问“你到这里需要多久？”显然，上海工作室的工程师没有意识到自己在距离深圳数千里外的上海。

最后，在客户端热更新方面，我们将5个人降到了2个人。这一切的能力，都是在试图提升开发者效率。

在我们从事这个产品的过程中，发现工作室内部有很多的反例（anti-patterns），当然这并不是他们自己的错误。我们发现的三个原因是：第一，数据无法分享，因为研发工具之间没有共享许可，这是很困难的，你必须逐个搞定；第二，工具集成起来很昂贵，这种事情在工作室内部发生了无数次，因为他们觉得自己做完了，有时候的确如此，但整体并不连贯。

第三个原因是，工具性能并没有优化到完整性能。不管是从算力还是能力角度，都有这种现象。

我们决定坐下来，了解这些反例，并找到我们如何从整体上让我们工作室的整个研发生态系统变得更好，所以我们创造了CloudFlow。

在CloudFlow内部有五种主要的能力，首先，我们希望集成大量的研发能力，不管是来自艺术还是研发方面，我们将所有不同的工具集成到一个巨大的管线，并且放到了CloudFlow里。另外，它是全球连接的，从工作室角度来看，腾讯开始扩张的时候，我们注意到一开始在本地部署很不错，然而如果要增加一个区域或者全球范围，会发生什么？

因此，我们想的是，在这个服务里我们能做什么才能让开发者变得更快？所以这里有个统一的IAM引擎处理所有东西，如果你要使用Perforce、版本系统，所有都在一个地方。你不需要通过不同的许可。

其四，系统内部还有一个深度分析引擎。很多时候，我们发现需要确保代码质量，而非只是符合标准，还要遵守工作室的政策。最后是API与ChatOps，这也被包含在内。

了解前面的信息之后，那么，它带来的结果是什么？

首先且最重要的是，我们在研发过程中很早期就开始转变，不再需要等待漫长的时间，聚焦于开发者。

这是CloudFlow之前的流程，你们可以发现，工程师和开发者们有时候可能不会发起build，他们等待日常build，有时候可能会进行茶歇或者别的活动，所以这是需要时间的。我们发现，问题发现率方面的事情在这个管线的更后期，因此，这是个问题。

我们想要实现的是，任何人都可以自己研发build，任何人随时都可以打造。他们输入代码之后，就立即会有多次迭代。

其次，我们要说的是可观察性，它应该是这个系统里的一等公民，这样数据就是完全透明的，所有人都可用。因为制作人或者开发者可能都在同一个房间里，当Perforce或者build系统缓慢的时候，你需要向其他人反映问题。

很明显，每个工作室都不一样，但在编译流程中，我们做的是能够追踪每一步，让开发者有灵活度开启或者关闭流程，还能够计算build系统的持续时长。

这是我们试图给所有人看的一个数据，以便让人们知道他们在做什么事情、以及它是如何影响系统本身和整个生态系统的。你不用启动P4显示器来看到底发生了什么，相反，他们可以去portal查看发生了什么。

那么，这带来了什么结果？整体的开发者效率提升，创造了很多的提升空间。现在，工作室内部有了更多的沟通。

最后，在可观察性方面，我们还启动了精细的访问控制，主要是为了保证质量的连贯性。在文件签入并部署时候我们就在分析，以便让它符合更多的标准。

最后还有一个报警政策引擎，主要用于预警，或许build太慢、commit变得更慢，所以，它可以以接近即时的效率启动triaging，让人们更主动。它的结果是，让版本工程师和机构在build管线之内根据他们想做的事情做出合理决策，这是很重要的。

再来说一下scaling的问题，随着腾讯在中国和新加坡，以及美国和欧洲的增长，从事不同IP研发的规模变得很庞大，光子、天美…所有这些人，他们是很大的工作室，他们在不同地点开设不同的办公室，不再局限于中国或者其他区域。我们得到的结果是，对我们的build做到可基于地理位置预测，以便降低编译时间，将其变从一个单一地点变成全世界范围。

左侧是我们的Customized Builder，我们有物理builder也有云端builder，另外，我们还在扩大整个build基础设施，他们在任何地方都可以使用。我们将很多的大型游戏，比如射击游戏的build时间从4小时降低到了2.5个小时。

提到故障域（failure domain）方面的结果，在你聚焦building的时候，经常会发生故障域，我们做的是试图通过功能和分支来隔绝故障域，而不是将整个build发送给QA并通过一系列的流程。

这是一个小型工作室通常发生的事情，属于变化前的图片。如果你有一个小型工作室，只有一两个软件工程师，你会通过政策（policy）管理东西。但随着人数越来越多、项目越来越大，这时候你就遇到了需要软件和政策引擎来解决所有事情。

我们所做的是，当一个用户推动代码，整个就会传送到云环境，很明显会有一个low balancer，他们检查builder，开始编译然后发送给一个不同的环境触发。这里他们要做的是支持大量不同的灵活性，我们所做的结果，是将编译失败率降低了50%。

我们想要做的是，随着功能和build的打造，我们希望它们自己能够输出到合适的环境中，所以我们得到的结果是一个非常快速的反馈系统。

夜间，我们同时有不同的管线，完整build通过政策引擎发送，然后自己发送到中国境内的智能机上，这些智能机每个都根据功能复制一个在线制作环境。到了早上，开发者来到的时候，他们就可以检查这些功能，确保一切顺利，他们可以利用整个环境来检查昨天晚上做的事情。我们几乎将时间降到了0。

在此之前，我们必须与运营交流，让他们发送并设置build，现在不再需要这么做了，一切都自动化了。

另外，系统内发生的还有其他功能，比如Shelling服务，协同与build等等。在QA方面，腾讯有手机库，这个系统可以让人们用远程连接CloudFlow的手机进行debug，当然，不会给你带来20fps或30fps的效果，但至少能够提供一定程度的用户体验。

最后，从美术研发周期来看，我们有云渲染器，降低了大量的美术资源测试，将人力测试时间降低了70%。

另外，我们还有一个开源的CI组件，感兴趣的可以扫描二维码尝试。