共计 3287 个字符，预计需要花费 9 分钟才能阅读完成。
在过往几期的 UWA Pipeline 最佳实际案例中，咱们分享了 如何通过 Pipeline 实现性能优化、性能治理、游戏内容验收和云真机系统的利用（实现批量真机设备的自动化测试，以及针对特效性能优化的形式），其实这些高效的办法并不局限游戏引擎。明天，分享一篇来自广州钛壳树的 UWA Pipeline 应用心得，这是一家致力于发明独特原创 IP、专一 Unreal 研发的游戏公司，看看 UWA Pipeline 如何帮忙 Unreal 研发团队达到锦上添花的成果。
常态化的引擎自动化编译、客户端主动打包、服务器继续部署，这是钛壳树团队在 Unreal 我的项目研发的过程中，应用 UWA Pipeline 实现的三大性能，大幅简化了工作流程，节俭了人力与工夫，进步了 CI/CD 的执行效率。以下分享出自钛壳树团队 CEO 的自述，具体介绍了具体实现的思路和形式，供宽广有相似需要的 Unreal 团队参考。
一、Unreal 引擎主动编译的实现
咱们应用 Windows 作为流水线节点，通过流水线的简略操作，疾速无效地实现不同的构建需要；通常 UE 引擎都有比拟严格的运行环境和编译条件，借助流水线和联结编译 IncrediBuild 能极大进步构建效率，升高构建复杂度，缩小人工干预的次数。
研发过程中批改 Unreal 引擎源码是必不可少的。获取源码后，除了有利于了解引擎的运行机制和不便调试，更多的是能够对引擎进行个性化定制，从而加强我的项目的游戏成果和可玩性。在构建流水线之前，大家能够通过 Pipeline 设置中的环境变量，来预设工作目录和工程门路，不便在后续的步骤中调用。
咱们的引擎编译流水线如下图所示，次要包含“Init”、“UpdateRepos”、“BuildAndCook”和“CommitRepos”四个阶段。
每个阶段的具体作用为：
第一阶段 Init
确保编译环境洁净、当前任务独占相干资源。如此运算力资源可能充分利用，并且能够防止资源占用抵触导致的报错。咱们的做法是：初始化环境、确保没有手动关上的编译过程。同时将节点的并发构建数量设置为 1，确保不会有多个工作并发执行。
第二阶段 UpdateRepos
进入预设的工作目录，通过 Git 和凭证治理，更新位于外部 Gitlab 的引擎源码 ue_tree。
第三阶段 BuildAndCook
编译引擎。进入工作目录调用 VisualStudio 编译命令，对引擎工程进行命令行编译，对应的批处理脚本如下：
通常编译引擎会占用很多 CPU 算力资源，须要破费很长时间能力实现编译，所以非必要状况下不执行 Rebuild 操作。咱们在这里通过 Pipeline 的参数化构建性能，在流水线上设定选项参数，提供多种编译形式（Build 和 Rebuild），在执行时，就能够将参数传递给编译器以明确编译模式。
第四阶段 CommitRepos
把最新的引擎提交到 SVN，用于接下来的开发工作。引擎编译后会生成若干目录，其中蕴含引擎运行所需的 DLL、执行程序以及两头文件。这里大家须要辨别两头文件的内容，防止把不必要的文件上传到 SVN 仓库中。
二、Unreal 客户端主动打包的实现
实现引擎编译后，接下来就是对游戏客户端进行编译打包。日常的继续构建，可能不便咱们随时跟进游戏研发进度，体验游戏的个性和玩法。Unreal 客户端打包时，大家须要留神引擎版本的应用，将官网版本和自定义版本区别开，免得成果不合乎预期。
咱们的打包流水线如下图所示，次要包含“Init”、“UpdateRepos”、“StartBuild”、“BuildAndCook”和“Commit”五个阶段。
每个阶段的具体作用为：
第一阶段 Init
与编译引擎的解决形式统一，确保工作独占编译资源，保障后续步骤顺利进行。
第二阶段 UpdateRepos
获取最新的代码和资源。游戏客户端除了波及开发代码和脚本外，还须要有数据资源，包含蓝图、配置数据、材质、模型、场景等等。其中代码和脚本应用 Gitlab 治理，数据资源应用 SVN 治理。
在打包的时候，大家须要再创立一个新的工作目录，把最新获取的代码和资源都拷贝到工作目录中，进行独立编译。
第三阶段 StartBuild
执行编译前的筹备工作。
设定工程应用的引擎版本，在开发时是通过右键菜单进行抉择，在流水线中则应用 VersionSelector.exe 命令解决。
抉择引擎后须要对工程生成对应的编译工具，包含：UnrealPak、Bootstrap、CrashReport 以及工程，命令如下。
第四阶段 BuildAndCook
将游戏工程生成最终能运行的程序或安装包。其中，Build 执行的是针对所选平台编译二进制可执行文件；Cook 是针对指标平台，将所援用的资源转换成对应的运行时格局。开始构建前，预设生成指标门路和两头目录，确保生成后的目录无效，给予下阶段应用。
第五阶段 Commit
提交构建后果到云空间。咱们在开发阶段不论是手动还是每天主动构建，都会依照日期寄存到公司外部的云空间中，不便开发人员获取和验证。
联合 Gitlab 实现提交时触发构建
UWA Pipeline 提供了近程构建性能，激活流水线设置中的近程构建，流水线会生成一个 URL 地址，咱们通过不同的参数配置触发流水线中对应的编译模式，达到和手动抉择参数一样的成果。
通过 Gitlab 的 Webhooks 填写对应的 URL 地址，通常在代码仓库 PR 时，就能够主动触发流水线运行，从而放慢构建和部署的频率，进步开发效率。
三、服务器继续部署的实现
咱们应用 Linux 作为流水线的节点，用于外部游戏服务的主动构建和部署，实现继续集成。
游戏服务是一个组件集群，波及到多个过程和依赖，为了进步构建速度、升高部署复杂度，通常反对一键部署。同时为了保障构建工作的互斥和步骤程序的正确，倡议大家将节点的并发构建数设为 1。同时，至于针对不同测试目标，须要在同一个节点进行继续集成。这就须要通过服务隔离、运行端口调配、第三方组件和应用容器部署等形式，实现多份服务过程的部署。
Pipeline 零碎设置 - 阶段治理 - 阶段设置内
能够配置节点的并发构建数，限度节点上能运行的工作数量
在单机部署测试环境中，将 Linux 作为流水线运行的节点时，还须要大家提前配置相干的数据库、缓存以及游戏服务所需的运行环境，咱们能够通过容器形式实现疾速配置。
咱们的服务器部署流水线如下图所示，次要包含“Update”、“Build”和“Reboot”三个阶段。
每个阶段的具体作用为：
第一阶段 Update
从外部 Gitlab 拉取最新代码（C/C++、Lua）和资源配置（Lua、JSON）。通过应用流水线提供的凭证治理和 Git 组件，在预设的工作目录中取得最新的代码和资源。
咱们在构建之前，通过 Pipeline 流水线设置，增加了选项参数或文本参数，设置版本指标和操作类型，不便后续在执行部署时可能依据需要进行构建。
第二阶段 Build
进入工程目录，编译 Framework、依赖库和游戏代码，生成 so 文件和脚本文件。
第三阶段 Reboot
依据预设的指标参数，从编译工作目录中把执行程序、so 文件、脚本复制到指标运行目录，进行运行过程中的游戏服务并重启。
定时构建
通过 Pipeline 提供的主动构建形式，设定好构建触发器，依据需要设定主动构建的频率，就能够在无人值守的状况下，实现流水线的定时主动构建。咱们现阶段的服务器构建仅限用于内部测试服应用，固定是每天构建一次。
感激钛壳树团队的精心分享，有雷同需要的 Unreal 团队都能够参考和借鉴。如果你被这个团队 CEO 的能力和态度所感动，违心退出广州钛壳树的话，现凋谢 UE4 引擎开发工程师、UE4 特效设计师等岗位，小编也十分乐意为你推荐。再次感激钛壳树团队对 UWA 的认可，在游戏行业工业化倒退的路上咱们又独特迈进了一步。
更多 UWA Pipeline 应用案例分享能够查看：
《乐享元游的 UWA Pipeline 最佳实际分享》
《一款 ARPG 游戏是如何搭建云真机系统的》
《再也不必焦虑特效造成的性能问题了》
想要理论体验 UWA Pipeline？请点击《收费试用 |UWA 性能保障体系全体验》，15 天 Pipeline 全服务试用就在眼前！
