假如你所在一个稍有规模的开发团队，那你一定会听过——自动构建。

笼统来说，所谓自动构建，就是自动编译出客户端包、程序包；但宏观来说，它更代表着一个概念——任务自动化。

自动构建，是一个高效率游戏开发团队的必经之路。假如你所在的团队没有经历过自动构建流程，那么相信你的团队肯定会在版本的编译和发布上，浪费相当多的时间，因为那是很多一些重复累赘的事情。

从成本的角度去考虑，自动构建，是相当重要的。曾经我所在的一个开发团队，并没有安排自动构建的流程，导致说，专门招了一个人，人工不停重复、机械化的做着出包、编译的流程，非常的愚蠢。

其实，这是一个相当简单的大号道理，而又很容易被研发团队所忽视：

完善自动构建的流程，将节省成吨的人力成本和时间成本。

这个道理，我倒是希望一些非技术人员，比如制作人、老板能看见并重视，把自动化作为软件研发的立身之本，不但让日常工作流能更加的流畅，还能节省人民币。

可以理解，大部分的游戏研发团队，尤其是初创中小型团队，都会将主要精力集中在游戏逻辑功能上面去，忽视自动化工具的开发。

“自动构建”这个话题，可大，也可小。今天，总结下，我在Unity游戏开发的工作中，“自动构建”的“编译机器”的选择经验和思考过程。

就我自己而言，我经历过3次不同的实践，来尝试过把自动编译的机器架构给搭建起来，前2次，都不那么靠谱。那就说说不靠谱的故事是怎么产生的吧，教训总比成功鸡汤来得有劲。

尝试1：Mac Mini + 虚拟机Windows

Unity游戏引擎目前来说，常见的开发操作系统平台有两个，一个是Windows，另一个是macOS。

其中，Windows版的Unity，是无法编译苹果版本的iOS、macOS游戏程序的（但能编出Xcode工程）。

在创业公司时，我想能够省钱的地方，那就省省。

所以我就选择了一台Mac Mini电脑，5000左右的价格，并且在上面通过Parallel Desktop虚拟化软件进行虚拟了一个Windows系统。

一台Mac Mini电脑的性能实在是太有限了，即使Mac Mini里配备的是一个性能不错的固态硬盘（读写1GB+），自动构建执行几个任务，性能还是太糟糕了。

为什么要虚拟出一个Windows操作系统呢？

因为当时想做成一个虚拟机，可以把一个操作系统，整个做成一个镜像，方便进行备份。

可是，性能实在是太慢了。

自动构建机器的一个最核心的需求——那就是性能。在后期，美术资源量上去了，Asset Bundle的一次打包占据了半个小时以上的时间，严重的影响了日常的工作流程。

所以，性能最大化，是选择构建机器的优先考虑维度。

尝试2：编译机阵列

由于回到了大公司，大公司内部有完善的、使用OpenStack云计算平台搭建起来的企业虚拟机平台，可以调用的机器资源，就多起来了。机器多，所以直接把它们做一个阵列规划吧。

实体机有2台，3个系统：

一台实体电脑Windows，上面通过虚拟机软件Hyper-V模拟出Linux（主要用于一些命令行批处理的任务）。

一台苹果电脑Mac mini，用于iOS的编译构建。

企业云虚拟机平台上，申请了3台，他们的系统分别是Windows，macOS，Linux。

就这样，一共有6个操作系统可供使用，组成一个阵列。当初的想法是，每个操作系统分别安排2台机子，任何任务都能进行主从任意执行，实现高可用，即同样任务，可以有两台机子顺利执行成功，当一台出问题了，Jenkins自动切换到新的机子进行任务，确保可用性。

理想是好的，可是跟现实有一点差距。

主要就是，需求，经常在变！

像前面所说的，主从两台机器都可以同时编译的困难就在这，开发环境的变化无时无刻都在进行。今天改了这个环境，然后两边又不同步了，在两边配置同步上就会花费不少的功夫。

实际运行时，很大一部分的自动构建任务，都放到了这3台企业云虚拟机平台上，原因很简单，因为这批企业云虚拟机的性能，比实体机还要好，这主要体现在硬盘性能上，功劳在于云平台的一些特性，不细说。

这个部署，看起来比较理想化。但是，实际操作起来，由于机器多，就涉及到管理问题了。

所以，简单最大化，是选择构建机器的其次考虑维度。

尝试3：黑苹果

这第二次尝试，是基于一个企业内部云的情况下才能实现的，这可能并不是很多小公司能实现的事情。

其实，前两种方案的尝试，都基于我的一个愚蠢的决定——我想帮公司省钱，用最小的钱买最小的机器，实现最大的效率。

完全没有必要。省这点钱，老板会意识到你的价值吗？不会懂的。（看“成本”的概念太多了，老喜欢抠这种。）

这次，决定从淘宝上面，定做一个黑苹果主机。

那是选用什么样的黑苹果主机比较好呢？以我最近选购的一款黑苹果为例，简要说一下它的配置：

价格一万出头。这个配置，其实最关键的两个点，一个是CPU，另一个就是他的硬盘了，三星960 pro这个固态硬盘高达2GB/s读写。

根据我经验，进行Unity引擎游戏的编译，最关键的是硬盘性能、CPU单核性能。

当然了，为什么要选用这一个CPU，而不是说至强Xeon系列的服务器CPU呢？因为游戏引擎在编译的时候它是单核在跑的单核性能最好的。服务器CPU的强项并不在于说单核性能，而是在于它的多核性能。

所以，选用单核性能更好的，够了。目前最牛逼单核性能的，正是i7 7700K。

(图:CPU单核性能天梯图，注意哦，最好的其实并不是最贵的。）

这一台新配的黑苹果机子。只是使用了一个独显，因为自动构建根本用不上显卡这回事。

就这么一台机子，就足够了——性能最大化、简单最大化。

因为Unity它是可以在苹果系统上面编译出Windows客户端的，所以使用mac系统作为编译机，是全能的，Android\Windows\iOS啥都行，很强的适应性。

如果你说你有需求，需要用到Linux进行的任务怎么办？比如说，我的项目就会有这个需求。

因为服务器是运行在Linux下的，编译服务器，那就需要一台Linux环境。

我的做法是——Docker。因为苹果系统上也可以运行Docker，而且它相对虚拟机也更加的轻量，性能也更好，所以直接使用了容器来进行服务器（Linux C++）的编译。

总结，花个一万来块，买个好点的机器吧，会让你省很多事。

后续更多

在组建的自动化构建方案是，我一般会“自动化构建”整理成三层：

控制台界面就是Jenkins，自动化脚本是处理一些杂项杂事（最关键的一层），编译脚本是处理具体客户端、服务器端等程序包的出包。

今天只总结了一些自动化构建的机器选择，下一篇，我会分享更多一些执行细节。