扰乱发布 Timeline 的隐性生产力成本

在过去的一个月里，你有多少次不得不放下手头的工作，立即行动起来，解决一个亟待解决的问题？最常见的游戏开发误区之一就是让看似无关紧要的低效小问题越滚越大。

当你的流程状态每天多次被打断时--无论是等待项目文件下载，还是解决另一个合并冲突--就是事情开始出现漏洞的时候。错误开始渗入你的代码。部署周期延长。通宵达旦成为常态。每一次失误都会产生摩擦，很快整个团队都会感受到这一点。挫折感与日俱增，士气开始动摇，很明显，你的工作室的工作方式行不通了。

实施DevOps 解决方案可以帮助您打破这种混乱的循环。有了正确的流程，你和团队中的每个人都可以减少任务切换的时间，重新集中精力完成最佳工作。定义明确的运行原则和一套正确的工具可以改善协作，加快部署周期。一次又一次地按时按质推出经过精心打磨的稳定游戏，同时最大限度地减少紧缩时间。

Unity 多年来与无数游戏开发人员和工作室合作，我们团队中的许多专家本身就是游戏开发人员。根据我们的经验，版本控制系统（VCS）是实现有效DevOps 的基础，但也可能成为工作室最大的痛点之一。这不是巧合。

在这本电子书中，我们收集了我们的产品和工程团队对三个最常见的版本控制陷阱的见解，这些陷阱阻碍了工作室做他们最擅长的事情：创作。请继续阅读，了解干扰发布 Timeline 的隐性生产力陷阱，以及 Unity DevOps 的版本控制组件等 VCS 解决方案如何帮助您重回正轨。

问题 1：平行发展

情况：一个项目，多个工作流程

除非你是一个人的团队，否则你会有几个团队成员为同一个项目工作。多一双手显然可以帮助你快速扩展，但也会减慢速度。

并行开发是指不同的团队成员在多个分支中工作，并能在稍后进行合并。编码员通常以这种方式工作，而艺术家由于要处理单个文件和资产，因此倾向于在有锁的单一分支上工作。

费用一去不复返的时光

这对生产力的影响是显而易见的，也是巨大的：损失了大量时间。

由于需要重做工作、解决合并冲突、追踪丢失的文件或等待下载之前已提交的修改，导致发布周期变慢、团队成员之间发生内部冲突，以及无法快速修复用户在游戏中发现的错误，从而降低了工作效率。

问题是失去工作和内部纷争

即使是单人游戏开发者使用 VCS 也有好处，但在与多个团队成员一起工作时，VCS 则是必不可少的。

如果不使用任何 Version Control，很快就会出现开发人员互相覆盖代码的情况，导致工作丢失和大量挫折。然而，如今即使使用常见的 VCS 工具，也会给游戏开发团队带来问题。

例如，如果整个团队都在使用Git，那么最常见的一种情况是，一些非技术性较强的团队成员，如美工人员，不会对该工具有充分的了解。他们很容易丢失更改，尤其是在无法锁定文件的情况下。而且，由于系统不透明、不容易操作，往往会过度依赖开发人员来解决问题，从而造成更多的工作损失。

由于 Git 无法锁定文件，许多游戏开发团队都在整个团队中使用 Perforce，以坚持使用单一系统和真实来源。不过，开发人员可能会对 Perforce 的 "任务流 "分支和合并方法的速度和性能感到不满。这会给本已复杂的流程再增加一层复杂性，尤其是在设置持续集成时。与我们交谈过的大多数创作者都表示，他们甚至不会尝试使用 Perforce 进行基于任务的开发。这不是一个理想的工作流程。

解决方案一致的项目组织

为文件整理等事项制定明确的规则，并确保这些规则得到广泛传播，从而使团队工作步调一致。

我还建议选择一款适合团队中每个人使用的 VCS。例如，艺术家应能独立为项目做出贡献，而不依赖程序员。通过实施每个人都能轻松使用的 Version Control 系统，对项目文件进行修改就不再是一个令人生畏的过程。

蒙特利尔工作室 KO_OP 在制作游戏《再见火山高》时，遇到了艺术家和程序员之间的不对称和沟通不畅问题。了解他们如何通过实施正确的 VCS 来解决阻碍进度的问题。

问题 2：冗余工具和孤岛

情况：不同的角色，不同的工具

UTeams 通常从单一版本控制解决方案开始，然后在遇到问题后转向多个系统。从根本上说，开发人员和艺术家需要不同的工作流程，因为他们使用的是代码而不是二进制文件。因此，团队中的美工人员会使用Perforce 等工具，而开发人员则使用 GitLab 或 GitHub。

费用事倍功半

在游戏开发过程中，需要分秒必争地快速迭代和测试新创意。虽然采用多种 Version Control 工具往往是为了解决同步或合并冲突等浪费时间的问题，但它们往往会加剧这些问题或造成其他消耗。例如，在没有双边集成的情况下，它们会增加创建新流程或工作流的时间，或增加维护两个系统的财务成本。

问题是更多工作流程、更多问题、更多维护

进一步解释一下，一个团队通常会从基于 Perforce 或 Git（如 GitLab/GitHub）的工作开始，并处理每种独特的工作流程所带来的痛苦。在 Perforce 中，他们失去了分布式工作和使用短暂分支的能力。使用 Git 时，由于分布式工作，他们会遇到文件存储方面的问题。团队可以使用 Git 大文件存储（LFS）来确保机器上只存储一个版本的二进制文件，但这是以牺牲速度和混乱的工作流程为代价的，它假装是集中式的，其实不是。

在使用多种解决方案时，工作室会遇到两个常见问题。首先是为项目维护两种类型的 Version Control 技术--这通常包括整合这两种技术的繁琐工作流程或过程。二是以知识和培训为中心。面对两种截然不同的系统，你需要这两方面的专家来帮助创作者或整个团队在出现问题时排除障碍。

解决方案评估和优化工具链

理想情况下，您希望所有资产都在同一版本控制系统中进行管理和版本控制，并根据团队的不同需求量身定制工作流程。

重要的是要检查你的流程和工具，然后决定它们是否真的适合你的工作室。

这样一来，您的工作室就可以避免许多常见的麻烦，不必创建不同的管道，将资产从一个团队转移到另一个团队。

我们建议使用可容纳多个工作流程的单一 VCS，或在系统间进行强大的集成，以便跟踪谁在处理什么工作以及每项资产的最新版本。

了解评估 Version Control 系统时需要考虑的事项，开始学习。

问题 3：太大，无法承诺

情况：项目文件需要经常更新

处理大型文件和二进制文件是制作游戏的独特要素之一，但这可能会导致版本控制方面的问题。比方说，你是一名使用 Git 的开发人员，正在尝试签入代码。要做到这一点，你首先需要用其他团队成员的最新更改更新你的工作区（这相当于拉动和推送）。

费用浪费更多时间

等待下载更新的时间就是在浪费时间。这些时间都是累积起来的。更快的系统可以让团队专注于完成任务，而不会因为工具而导致项目停滞。

问题是工作流程中断

有些版本控制系统在处理大型二进制文件时速度极慢。试想一下，当你从点击更新到签到之间不得不等待五分钟，终于可以继续你的生活时，是多么令人沮丧。

在游戏开发中，你需要快速行动。如果在游戏中实施更改或应对由于流水线初期效率低下而导致的 Bug 所需的时间过长，那么这些问题只会在日后变得更加复杂。

许多工作室使用 Perforce 或 Git LFS 等解决方案来解决大型二进制资产的问题，但每种解决方案都有左侧列出的同样的折衷方案。

解决方案使用基于文件的版本控制

选择基于文件的 VCS 可以大大加快工作速度。

有了这样的系统，贡献者可以只下载他们需要修改的文件，而不是整个项目。这种方法更快、更安全，但你必须确保每个人都以同样的方式整理文件，这样才能真正有效。

在选择版本控制解决方案时要提前考虑，因为这可以为你日后省去很多麻烦。游戏规模越来越大，也越来越复杂--越早实施正确的 Version Control 系统，就越能获得持久的成功。

了解Sycoforge在游戏《重返南格里姆》中采用的迭代开发方法，以及 Unity Version Control 如何帮助他们适应项目规模的不断扩大。

针对游戏开发的 Unity 版本控制

版本控制是 DevOps 的基础，但也是游戏工作室的核心冲突源，而且真正适用于每个贡献者的解决方案并不多。Unity DevOps 的 Version Control 在支持游戏开发人员方面具有独特的优势，正是因为它解决了这些浪费时间的问题。下面是它与竞争对手的比较。

平行发展

有效促进并行开发是必须的，而团队中的每个成员可能都有不同的偏好。基于 Git 的工具，如 GitHub、GitLab 或 BitBucket，是目前最流行的版本控制系统，尤其是在开发人员中。由于 Git 广受欢迎，用户将可以使用大量的用户增强功能、集成和互操作性。然而，随着团队和项目规模的扩大，许多大型和 AAA 级游戏工作室开始使用 Perforce 这样的集中式工作流程解决方案，以便在处理大型二进制资产时更好地满足美术师和非技术用户的需求。

由于 Unity 版本控制系统具有强大的分支和合并功能，可以帮助开发人员集中工作，并为美工人员锁定文件。如果您在 Unity 编辑器中工作，Version Control 与 Unity UI 的无缝集成可促进协作。

冗余工具和孤岛

虽然艺术家和程序员在使用版本控制的方式上可能普遍有不同的偏好，但重要的是要知道在两个方向上过度修正的利弊。特别是在远程工作时，拥有一个单一的 Version Control 系统和 "真相源 "可以帮助消除维护多个不同管道所带来的许多挫折和浪费时间的后果。

即使有各种优缺点，GitHub、Perforce 甚至 Dropbox 或 Google Drive 等很多系统都可以根据自己的工作流程进行设置。寻求集成或扩展来帮助减少一些协作问题，或者选择为各方设计的单一系统。

Unity Version Control 支持在不同模式下使用单个版本库。该功能让您可以使用多个工作流程，而无需维护和连接两个不同的系统。

在 Unity 版本控制中，美工人员可以使用 Gluon UI 以集中模式处理版本库，从而模拟与 Perforce 等解决方案相同的工作方式。开发人员可以使用默认的用户界面，像在分布式模式下一样使用版本库，从而模拟与 GitHub 或 GitLab 等基于 Git 的解决方案相同的工作流程。

太大，无法承诺

游戏开发意味着要处理大型项目。随着工作室规模的扩大，源码控制管理系统也应能随之扩大。

虽然 Git 的分布式模型并不是为游戏开发而设计的，但有几种扩展工具可以让 Git 更轻松地处理二进制文件，其中以 Git-LFS 的应用最为广泛。不过，Git 在设计之初并没有考虑到艺术资产的管理，这也是大型工作室通常采用 Perforce 等其他解决方案的原因。

在处理大文件方面，Unity Version Control 是市场上性能最好的解决方案，非常适合游戏开发。它大大减少了等待文件加载的停机时间--Unity Version Control 的速度可比其他解决方案快 5-8 倍。你仍然要处理同样的内容，但现在你不用每天多次等待五分钟的下载了。相反，您可以在几秒钟内获得所需的信息。

随心创造，无损品质

Unity Version Control 专为游戏开发而设计，可为各种规模工作室的艺术家和开发人员提供支持。它为艺术家提供了基于文件的工作流程和直观的用户界面，还为程序员提供了强大的分支和合并功能，确保所有用户都能从改进的协作和迭代灵活性中受益。

Unity Version Control 可以集中管理工作，而无需克隆版本库，它还支持庞大的文件和版本库，并能进行快速的广域网优化数据传输。其 Gluon 工作流程工具可让最不懂技术的团队成员轻松应用任何版本控制协议。

使用 Unity DevOps 加速工作流程并构建 DevOps 工具链。不折不扣地创作，高效率地工作，以您所期望的质量按时推向市场。今天就开始免费使用。