本文将由Unity官方工程师Alex Lian为大家揭秘Unity版本发布管理系统，并介绍我们为提高产品稳定性所做的努力。

随着5.4版本的发布，Unity的构建方式也发生了巨大变化。因为我们正全方位不断成长，所以这种变化也成为了常态。我们的开发者与QA团队已从我加入时的100多人发展到现已超过400人。在5.1-5.3的产品周期里为了这样的成长我们付出了很多，现在也仍保持这样的节奏以应对变化带来的压力。

去年我们认识到，随着底层代码与系统的改进，我们的可用性、稳定性及接受度都获得不小的成功。虽然我们一直在持续不断尝试改进，但我想为大家列举此次发布采取的一些步骤，并在这个系列文章中多讨论些更为深入的内容。

这里介绍的内容并一定是什么很新颖的想法，但希望能以此说明规模与范围所要求的必要改变。简单的说，这是对于常规性自我审视改进过程的一瞥，也是Unity目前正在践行的改进方向。

我们先从一些基本的东西开始，而后将再深入更大的主题。

适度升级构建服务器集群，并且构建主服务器（katana）相比前几轮更快（且持续改进中）

值得一提的古怪情况是，我们那相当复杂的构建服务器集群（从TeamCity升级到Katana后变得更大更复杂了）现在正限制在我们位于哥本哈根的服务器室中。我们受到了物理空间、制冷及电能的限制！一些技术架构上的问题导致我们无法在短期内进行迁移，但我们迁移至外部数据中心的项目即将完成。关于这点后续再聊。

拥有高度自动化、多平台支持，以及分布式开发的构建服务器集群是支撑我们开发速度与质量的基础设施中非常关键的一个组成部分。因为平台数量众多（维护，配置，以及最简单的空间方面），对于单个开发者来说几乎不可能进行完全的构建与本地测试。[旁白：每个开始接触Unity的开发人员，包括我自己，都认为“构建服务器集群并不是什么困难的事情，我们在某某工作室或某某公司就做的很好。”一旦他们了解后……这的确就是那么困难。]

所以，在5.4发布周期即将开始前，我们将所有支架服务器都升级到最新的硬件，并推送了一个新版本的Katana构建主服务器，这显著提升了构建速度。


从2016年1月1日到2016年7月29日间的构建数聚合图表。线是每个构建的“平均围墙时间”蓝色线则是“平均实际构建时间”其差异就是一个构建可能需要等待的子构建依赖时间。

这个图表中有个明显的缺口，这个很长的维护窗口是因为我们的工程工具操作团队发现了一个CEPH集群中的BUG而造成的。这样通过尽可能减少错误的发生，同样也提高了流水线性能并改进了整体的服务器集群性能。

每个CPU周期对你们很重要，对我们也一样。我们正持续投资以使构建服务器集群具有更好的伸缩性及更快的速度，从而不仅能满足我们自己的需求，还能最终满足大家的需求。

将版本重叠最小化，曾冻结5.5的开发以便全力支持5.4

在5.0-5.3周期中，我们为了维持季度发布计划表不得不非常费力的进行重叠。除去开发上的考虑，这对整个组织，从开发者、QA以及对构建基础设施的支持都产生了数倍的压力。在5.3发布时，我们同时管理着5个版本（4.7，5.0 - 5.3），并已着手开始进行5.4的开发，所以加起来总共有6个版本！

这导致注意力大量分散，更不用说跟踪具体的焦点。

在5.4期间，我们明确将5.5的开发工作推迟，只在最近才对其有一些小范围的关注。从路线图中可以看到5.5中有一些新功能，但更少也更可控了。通过聚焦低量高质，我们打算重新加快周期，并减少对于重叠版本的关注。

通过内置QA更加突出团队，改善测试环节

这看起来像个琐碎的话题，而且经常会扯到一些有关敏捷开发或其他管理方面的傻问题，我们还是决定对嵌入式QA做进一步的实验。原因很简单：开发人员经常自顾自的去工作，“实现”并只在“完成”后才交给QA。

通过让QA更早的更具存在感的参与整个过程：
我们改善了计划表，因为QA成员能获得更好的全局总览，并能更好的参与其中 QA从来不会对于未发现的工作感到惊讶 能够更早发现工作流问题 能在Bug产生时就发现它们 我们甚至能拥有肩并肩的用法及开发，就像坐在游戏设计师旁边看着他使用新工具一样 当我们将功能分支带到发布分支之后，我们将更具自信


目前，我们看到的好处要远大于任何顾虑，我们的大多数团队都能乐意拥抱这一变化。同样，没有什么好惊讶的。我们正做更多这样的事，而这带来了变化。

更紧密的团队工作带来的一个结果就是在开发过程中会产生很棒的有关功能审核及更改的测试报告。来看几个例子：
5.4中的 Image Effect Bloom (可在bitbucket下载) 即将发布的 alpha/beta版本中的 Particle Noise 即将发布的beta版本中的尾迹/线段渲染器



5.2 – 5.4版本 去年的编辑器启动数据


从数字上可以看到，这对于使用率提升有很明显的效果，也帮助我们获得了更广的覆盖面。

提高内部QA过程数量，改善了测试覆盖率

我们不能将所有的测试覆盖需求丢给beta测试。所以，我们的QA小组站了出来，增加了测试数，并使用新方法进行测试以发现用户可能发现的问题。我们将用于早期新功能测试的方法重新定义并重新聚焦为一个在我们内部称为功能测试框架（Feature Testing Framework） - 这个主题将在后面的文章中介绍。

结合前面提到的QA嵌入，我们得以更早的发现问题，并用更短的反应时间在问题产生前后修正问题。

我们的测试覆盖面更大了。我们最近关于自动测试的代码覆盖率测试显示，现在编辑器与运行时源代码已达到70%的功能覆盖，约50%的条件/决策覆盖。我们不断的增加更进一步的测试，这应能在未来减少回归测试的次数。

我们将以更高的标准要求自己

Unity成长了很多，用户对我们的期望也增加了很多。我们很乐意去满足这些期望，因此我们正全力以赴的工作，努力实现更好更高的质量。Atlassian的公司价值观中有一句“不要 #@!% 客户”，我们受其启发， “不要 !@#$ 主干” 已深入我们心中。

这可能很粗鲁，但大家能很快心领神会。有争论时，只要问一自己一个问题就能很快解决。一个更改就究竟会导致事情归于何处？

脑子里有了这样的改变后，我们对审阅过程的要求也更高了，尝试量化风险并且纪律性更高。我们现在还更重视稳定性、可靠性以及质量。我们问自己代码的可维护性怎么样，或者当下个开发人员遇到某个给定的更改时会怎么说。

我们现在同时还在进行深入挖掘与重构。通过修复BUG倾向于质量为重的做法也相应符合了对于修正底层代码基础的投资。其目的是使之模块化且可维护性更好，从而使测试更加简单。当然，这最终都是为了大家的利益。

未来的主题

今天说的够多了，但是请保持关注，在这个系列文章中我将为大家分享以下主题：

改变我们的bug优先级系统，反应“用户痛点” 保持我们的发布分支与主干比以前任何一个版本都更稳定，测试更是一路“绿灯” 更多的性能测试覆盖，监控最危险的用户关于回归问题的抱怨 “项目升级”聚焦于使用户尽可能的从上一版本干净升级 可以获得发布版本的基本运行数据的崩溃追踪工具 将更多信息更早的送到测试者手中


如果你有兴趣，希望你能喜欢这一系列。下一篇再见（或下个版本）。

Unity, 发布, 管理

锐亚教育 锐亚科技 unity unity教程