当前位置：首页 > ai >正文

游戏开发中的CI/CD优化案例：知名游戏公司Gearbox使用TeamCity简化CI/CD流程

ai 2025/6/28 6:40:38

案例背景

关于Gearbox：

Gearbox 是一家美国电子游戏公司，总部位于德克萨斯州弗里斯科，靠近达拉斯。Gearbox 成立于1999年，推出过多款史上最具代表性的视频游戏，包括《半衰期》、《战火兄弟连》以及《无主之地》。

团队介绍：

Steve和Phillip是Gearbox 核心发布工程团队的成员。团队分布在魁北克市、蒙特利尔和弗里斯科，负责为公司的所有项目提供服务，并设置自动化来满足每个人的需求。启动一个新项目时，团队会立即在 Perforce 中建立一个仓库，并确保 TeamCity 中有一个项目与其绑定。

团队试图为每个项目分配一个人。每个发布工程师都是发布团队和游戏项目的一部分。这使团队能够响应每个项目在自动化方面的需求。

它还让发布工程师可以分享有关 TeamCity 最佳做法的知识，并在其他项目需要帮助时介入。得益于标准化的 CI/CD 做法和可重用的项目模板，他们可以快速应对任何问题。

Gearbox的技术栈：

团队以 Perforce 作为版本控制系统，使用 Unreal 作为游戏引擎。团队构建了位于Unreal 之上的 C# 脚本，TeamCity 与之交互。这一层与 CI 无关，可以处理 Unity 和 Unreal 项目。

团队还通过 Artifactory 为构建机器和存储使用AWS，对于Artifactory，他们使用的是 TeamCity JFrog 插件。

为什么团队决定寻找新的CI/CD解决方案

Gearbox之前使用的 CI/CD 解决方案存在一些局限性，与Perforce的集成很差。团队使用的 CI/CD 工具不提供 TeamCity 中提供的个人构建，并且在构建步骤之间传递信息也是一个挑战。

“有一个产品我们在内部使用了很长时间。我们尝试过换到不同的竞品，但都没有成功。然后，一些来自另一家游戏公司的同行说，‘我们使用过TeamCity。’我们调查了一下，发现 TeamCity 可以解决我们的很多问题。”

— Phillip Peterson，高级发布工程师

使用TeamCity 简化构建步骤连接：

在 Gearbox 使用的一个竞品中，在两个构建步骤之间建立连接的过程非常繁琐。例如，有一个构建步骤会产生一个工件，团队想将工件的名称传递给后续作业，但在两个构建步骤之间进行对话就是一个巨大的障碍。相比之下，这在 TeamCity 中极其简单。

让团队感到苦恼的另一件事是在构建步骤之间传递构建结果，而 TeamCity 提供的依赖项途径解决了这一问题。

新CI/CD解决方案的选择标准

跨项目应用批量更改：

在新的 CI/CD 解决方案中，团队主要关注两个方面。其一是能否轻松跨项目应用批量更改。此前，团队需要从头开始每个项目。随着项目数量的增加，团队开始寻找让他们能够复制粘贴项目设置、更改名称和运行项目的模板。

人性化 UI：

第二个要求是人性化 UI，让最终用户和管理员能够轻松使用新的 CI/CD 工具。

“一个竞品的 UI 非常不友好。在 CI/CD 系统里，我应该感觉很踏实，做什么都不会坏。我认为 TeamCity 的 UI 非常出色。浏览的时候，你会相信系统运作良好。”

— Steve Fortier，首席发布工程师

TeamCity 精致的 UI 使其非常容易被接受。在团队证明概念可行后，一番展示就很快说服其他人转向新的 CI/CD 解决方案。

访问管理：

Gearbox 选择新 CI/CD 解决方案的另一个因素是访问管理及其在 TeamCity 中的运作方式。团队当时正在寻找一种按项目编辑用户访问权限的方法。

在 TeamCity 中，您可以创建层次结构，人员可以在层次结构中获得对项目的访问权限，访问所有子项目。这对 Gearbox 产生了巨大的影响。

在TeamCity Cloud与On-Premises之间选择：

在团队听说 TeamCity 后，他们最初尝试的是本地部署版本。不过，TeamCity Cloud 的选项让 Gearbox 的 IT 部门非常高兴，因为他们知道唯一需要做的就是设置身份验证。这也让过渡速度远比此前估计的本地部署设置速度快得多。

TeamCity Cloud 用户可以在 JetBrains 托管和自托管构建代理之间选择。Gearbox 团队使用自托管代理，能够完全自定义运行构建的环境。

过渡过程

过渡到 TeamCity 时，团队开始从头开始设置所有项目。不过，他们故意让旧构建脚本与 CI 系统无关。这意味着虽然是在 TeamCity 中设置大量新项目，他们也只是将旧系统中的现有命令复制粘贴到其中。

经过几次讨论如何组织项目的研讨会后，团队得以在短短 6 周内从旧的 CI 解决方案转移到 TeamCity。

CI/CD指标

目前，Gearbox 在TeamCity Cloud 中拥有 340 个提交者和 138 个项目。

团队使用托管在自己的 AWS 账户中的代理以及 TeamCity 的云配置文件。根据构建的需要，TeamCity 会自动从团队使用的“base”、“high”、“mega”或“GPU”实例中进行选择。

过渡期间，Gearbox 采用了他们为之前的 CI/CD 解决方案启动的 Amazon Machine Image (AMI)，并安装了 TeamCity。如此一来，Gearbox 只需维护一个 AMI，因为旧系统和新系统都使用同一个 AMI。这使迁移过程更加容易。

TeamCity中的构建链

Gearbox 在整个 CI/CD 流程中广泛使用构建链。Unreal 流程经历 5 个阶段：编译、烘焙、暂存、打包和发布。

Gearbox 构建链示例

如果一款游戏将在不到 12 小时内发布，但在链中的某个位置，一个被填满的卷停止了进程，那么，扩展卷再重新开始是不现实的，时间完全不够。

在 TeamCity 的帮助下，Gearbox 团队能够将这些部分分解成自己的构建。这样，如果在构建流程中卷已满并且必须扩展，那么构建会失败，但团队可以快速处理。他们可以从中断的地方重新启动流程，重新挂载该持久卷，然后从原来的地方继续。这要归功于 TeamCity 的内置构建链优化，使用快照依赖项时，重用构建会对其起到促进作用。