Gearbox 如何使用 TeamCity 简化其 CI/CD 流程

公司信息

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

我们与 Gearbox 的首席发布工程师 Steve Fortier 和高级发布工程师 Phillip Peterson 一起讨论了 Gearbox 如何在 JetBrains TeamCity 的帮助下标准化和增强了他们的 CI/CD 流程。

团队介绍

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 个阶段：编译、烘焙、暂存、打包和发布。

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

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

Gearbox 的测试流程：从本地到集中的动态编排

在 Gearbox，当开发者开始运行本地测试时，TeamCity 可以发挥更多作用，集中运行整套测试。CI/CD 系统还可以在不同类型的机器上动态编排这些测试运行，在给定时刻根据需要启动尽可能多的机器，并在过后将其关闭以优化资源。

在 Gearbox 使用 TeamCity 简化项目设置和资源共享

轻松共享知识

TeamCity 帮助 Gearbox 解决的最大挑战之一是启动新项目。在其他方案中，每个项目都必须从头开始。随着项目的发展，它们会彼此偏离，变得相当不同，让公司在每个项目上都需要一个主题专家。这使团队之间难以共享知识，导致开发过程中出现瓶颈，并增加出错和不一致的风险。

更高的生产力

自从团队采用 TeamCity 作为 CI/CD 解决方案后，事情就简单多了。得益于模板，团队可以跨项目共享资源。只要熟悉一个项目，也就熟悉了所有项目。这有助于团队提高生产力并专注于高效开发。

在 EC2 实例方面显著节省资源

在 Gearbox 之前的 CI 解决方案中，每次构建都会构建编辑器，这可能需要长达一个小时的时间。现在，团队可以将该步骤整合到自己的构建中，然后在各处重用。这帮助团队在 EC2 实例方面节省了大量资源，因为他们不必再重复编译相同的东西。

Gearbox 的配置即代码

当 Gearbox 开始使用 Kotlin 进行项目配置时，团队充满期待。即使是那些对 Kotlin 经验不多的人也能够很快理解并开始使用。“的确有一个学习曲线，但总的来说，氛围是积极的。”Steve Fortier 说。

目前，需要在一个项目中更改内容时，团队会使用 UI。如果是更改特定构建配置在多个项目中的工作方式，团队将使用 Kotlin。对于 Gearbox 来说，灵活使用这种混合方法进行项目配置是 TeamCity 的另一大亮点。

Gearbox 的未来计划

Gearbox 的目标是通过实现个人构建来增强对 TeamCity 的使用，提升提交的可靠度并为 QA 测试提供有效构建。团队还希望提高构建速度、缩短构建链并最大程度地减少失败。

团队目前跟踪服务器性能、构建持续时间和构建失败，但计划包括更精细的指标，例如工件大小和队列持续时间。他们的目标是利用 TeamCity 的一系列可自定义功能建立更高效的 CI 流程，节省时间并确保构建的可靠性。

结论

切换到 TeamCity Cloud 在多个方面改进了 Gearbox 的 CI/CD 做法。

• 易于采用的特性使团队能够在短短 6 周内从之前的 CI 解决方案迁移到 TeamCity。
• TeamCity 的内置 Perforce 集成帮助团队简化了整个 CI/CD 流程，并节省了团队原本要花在创建集成变通方案上的时间。
• 借助 TeamCity 的项目模板，团队现在可以按照标准化做法更快、更轻松地启动新项目。
• 得益于 TeamCity 的云解决方案和人性化 UI，团队发现维护项目比以前容易得多。

TeamCity 还帮助 Gearbox 在 EC2 实例方面实现了显著节省，因为使用依赖项可以避免多次重复编译。