Unity Downloader：通过嵌入持续集成来增强编辑器
长久以来，Unity一直使用Katana进行持续集成 。在我们发布版本之前，Katana用于构建版本，并运行所有内部测试套件。
当Unity员工希望运行编辑器时，他们可以使用三种方法解决来自内部的需求：
访问内部网站下载即将推出的版本。
使用源代码在本地构建编辑器。
使用Unity Hub获取最新的发布版本。
资源包机制
当我们决定对Unity编辑器进行演变并开始使用资源包机制，越来越多Unity功能从主Unity代码库移出，保存到单独的资源包代码库中。
这帮助我们加速版本的发布，有助于使一些Unity功能和扩展达到新的水平，这也是实现DOTS路线图上非常必要的一步。但就像其它技术转变过程一样，这项新的技术范例带来了一系列的挑战。
我们希望可以验证和发布这些资源包，以确保每个资源包在不同编辑器版本上有着良好的运行效果，满足Unity内部对产品质量要求。资源包有自己的代码库，并在上面运行的新持续集成系统。
为了成功实现资源包的持续集成，最重要的是它的主要依赖－Unity编辑器。我们并没有无缝而统一的方法，可以让资源包的持续集成请求特别的编辑器版本。
因此去年，我们加入很多资源包代码库，它们有各自的自定义方法来获取编辑器。有些资源包会在安装有编辑器的实际机器上运行持续集成，在每个需要的版本都有硬编码路径。
其它资源包创建的自定义工具会触发Katana构建，并且在持续集成的机器下载资源包。但所有解决方案都用了特定的方法，并不是特别通用。
去年9月，Unity开发人员齐聚“Fridays Are For Fun”活动，我们在活动上着手尝试创造一种通用方法来为持续集成获取编辑器，使它可以为尽可能多的用户工作。最终，Unity Downloader诞生了。
什么是Unity Downloader
Unity Downloader是一个使用Python编写的命令行工具，它支持我们所拥有的任何Unity版本，分支和修改版本。
Unity Downloader允许Unity员工在MacOS，Windows和Linux系统下载Unity 5.0及更高的版本，并且使用到WebGL，Android等组件。
实际上，Unity Downloader并不简单，它在后台会执行一些我们所看不到的复杂工作。例如：
检查Unity 2019.1的最新版本是什么？
该版本修改了什么？
我们是否有面向该版本的构建？
当用户请求常用内容时，我们如何减少不必要的等待时间？
因此，Unity Downloader是以下功能的组合：
命令行界面（CLI）
它可以请求，下载和提取编辑器安装程序，并将它们组合为有效的编辑器安装。
请求的编辑器缓存
我们现在有其中三个请求的编辑器，所处的位置可以方便构建系统快速下载这些编辑器。
在用户请求发布版本时，它也使用公开下载链接作为第四个来源。
后端
后端有和命令行界面通信的REST API，用于请求新编辑器构建在Katana中触发。
它还监视触发的构建过程，并将进展传递给命令行界面。然后它会把完成的构建放到缓存中，使命令行界面可以下载这些构建内容。
预取器
预取器是一个在定时作业中运行的小型脚本，它会监视我们最常用的分支，例如Trunk主干分支，并确保这些分支的构建在得到新的批时触发。这是为了在用户请求下载主干编辑器时，最小化等待时间，因为该请求可能会频繁出现。
清洁器脚本
我们无法永远保存所有构建版本。这些内容占据大量空间，我们倾向于在新版本推出后不久，停止使用较老的修改版本，因此该脚本会清空缓存，删除过去30天内未下载过的文件。
准备好这些后，我们可以在临时的虚拟机运行持续集成，虚拟机会在在作业结束后被销毁，然后重新创建干净状态的虚拟机。这便于我们的团队处理资源包的持续集成，并对任何希望测试的Unity版本运行工具。
如果开发人员需要在编辑器为资源包进行Bug修复，确保资源包发布后编辑器会运行资源包持续集成。我们可以通过修改Unity Downloader命令行为以下命令，告诉持续集成使用该分支来运行。
上述请求的流程在后台的流程如下：
由于我们请求了分支，因此需要修改版本，所以命令行界面会向后端请求2019.1/myFix分支的最新修改版本，这样会返回abc123456789。
命令行界面会查询缓存，了解缓存是否有编辑器以及修改版本的il2cpp构建目标。如果有，它会开始下载修改版本并完成操作。如果缺少缓存，它会继续执行后面的步骤。
现在它会请求后端为当前操作系统获取修改版本的编辑器和il2cpp组件。
后端首先会查看Katana的构建内容，了解是否已经有相应的版本。如果没有，它会触发构建过程，和命令行界面进行通信，了解完成构建的大致时间，并给命令行界面提供Katana版本的URL，以便用户了解耗时较长的原因。
在构建完成时，后端会把构建内容上传到缓存，然后告知命令行界面：它现在可以重新执行第二步操作。
命令行界面会下载并提取构建内容，用户可以在空闲时间启动构建版本。
以上流程便是整个操作过程的简化版本。
当前状况
所有内部的资源包持续集成现在以特别的方法使用Unity Downloader。因为该过程由我们的持续集成工具处理，可以在开始构建和运行测试前调用Unity Downloader。
大多数资源包代码库的所有者不知道这一点，代码库所有者只需要指定想要的版本或分支，就可以获取相应内容。
下面是今年5月的一些统计数据：
Unity编辑器下载次数为42,000。
Unity编辑器的组件下载次数为18,000。
80%的使用率来自构建农场的虚拟机，剩余20%来自Unity员工的机器。
自从我们在去年11月开始使用统计指标，已经累计下载了30万个文件。
下面展示了1个月内使用量的峰值和低谷。我们可以从中看出持续集成部分（峰值）和周末间歇部分（平坦部分）的夜间任务。
对于持续集成，用例非常明显，其中很大部分流量来自真实用户。有些Unity开发人员会通过使用持续集成加强工作流程。
Unity Downloader有一种情况非常实用：通过二分法寻找Bug产生的原因。由于我们希望找到某个Bug在哪个Unity正式版本出现，我们可以获取出现Bug的修改版范围，以及此前的正式版本。
通过使用Unity Downloader，我们可以预先触发合理情况下尽可能多的中间修改版本的构建过程。
设置-skip-download标识并略去--wait标识是确保缓存内容并触发构建的最快方法，这些调用的快捷更替会确保触发未构建的内容。
这样也会确保在二分法的测试过程，经过前几次修改版的测试后，剩余修改版本可以进行构建，并为下载做准备。以更为传统的方法执行该过程并在本地构建每个修改版本则是非常耗时的任务。
另一种情况是在本地快速测试Unity项目。为了给项目下载并启动编辑器，我们可以执行以下操作。
这样将获取适合项目的确切编辑器版本，并且不会触发脚本更新程序等。
由于Unity Downloader在我们的自动化流程中广泛使用，并帮助我们的工作流程，因此我们认为这是成功的工具。但它在设计仍存在一些问题，包括：
命令行界面有很多业务逻辑，它知道所有已知组件的信息以及这些组件的位置，这导致我们需要非常频繁的发布新版本。
我们也没有处理好命令行参数，选择子命令方法会增加新功能，而且不会使体验容易变得混乱。
因为所有缓存目前都在欧洲，对于Unity非欧洲员工，命令行界面的下载速度不是很好。
我们无法和用户分享其中的任何内容。
未来展望
Unity Downloader已经达到了足够的成熟度，可以在Unity内部广泛使用，特别是用于持续集成，我们希望调查Unity用户使用的选项。
Unity Downloader极大的改善了Unity内部的工作流程，而且我们相信它会有助于其它问题的解决。所以，我们对其未来计划是完全重构Unity Downloader。
考虑以上原因，我们希望用户参与进来，从而在我们找到扩展用途的方法后，使新版本的工具更适合外部需求。
为了确保新版Unity Downloader符合用户的需求，特别是在持续集成方面，我们希望得到用户的反馈。
你是否认为需要能够从选择的终端下载任何或所有已发布的编辑器版本？
你是否使用到的持续集成解决方案，如果是，为了实现它需要满足哪些技术要求？
即使你不打算自己使用该工具，我们也希望了解你不打算使用它的原因。我们会一直聆听您的反馈 。
更多Unity最新精彩内容，尽在Unity Connect平台(Connect.unity.com)。下载Unity Connect APP，请点击此处。 观看部分Unity官方视频，请关注B站帐户：Unity官方。
推荐阅读
官方活动
活动一：Unity官方教师培训课程
7月29日－8月2日将举办Unity官方教师培训课程，现诚邀广大教师一同学习分享Unity最新技术，探讨Unity在教育教学中的创新应用。［了解详情......］
培训时间：7月29日－8月2日，共5天
报名地址：
https://www.bagevent.com/event/5329696
活动二：成为Unity Buddy，享受专属福利
7月22日－8月21日加入Unity Connect，创建个人频道，成为与Unity社区同行的伙伴-Unity Buddy，享受专属福利。［了解详情......］
喜欢本文，请点“在看”