【译】KATANA：使用开源工具来做持续集成

原文地址：http://blogs.unity3d.com/2014/06/02/katana-leveraging-open-source-tools-for-continuous-integration/

原文作者未做版权声明，视为共享知识产权进入公共领域，自动获得授权。

　　大家好！我是Na’Tosha，尽管很多人认识我是因为我在Unity的Linux平台团队所做的工作，但其实我的主要身份是研发的构建和基础设施团队的程序组长。在2011年10月的时候，我写了一篇Blog： BuildEngineering and Infrastructure: How Unity Does It。这些年里Unity发生了很多变化，基础设施部分也发生了很多改变。两个主要变化是用来托管和代码审查的工具以及我们自动构建集成的解决方案。

　　Unity曾经使用JetBrains的TeamCity作为自动构建和测试工具。随着Unity研发团队的增多，对于构建的需求也有多个维度（即用户的数量、变更的数量和同步分支的数量）。我们需要每天构建几千次，这暴露了多个方面的性能问题：服务器响应缓慢、无法解决的不明原因的错误、新的提交响应缓慢、网页需要几分钟才能加载等等。经过与TeamCity的制造商一年反复的讨论以及的不断恶化，我们觉得最好的解决方法是采用一个适合我们特定需求的解决方案（当你有一个类似我们这样的工作，结合我们的规模以及对工具所要求的可扩展性和灵活性，很难有一个现成的解决方案）。作为一个长期的开源爱好者，我觉得这是一个很好的机会用开源的力量来解决我们的问题。经过一些调研以后，我决定我们将基于Buildbot，一个被Mozilla,Python和其他项目采用的开源持续集成框架，来构建一个定制的解决方案。Buildbot是基于Twisted event-driven网络引擎使用Python开发的。

回顾

阶段1:原型和概念验证

　　当时是2012年9月，幸运的是，我们刚刚扩充了构建工程团队并有一位新的同事加入我们-Maria，她有过Buildbot的工作经验。我们知道这将是一个大项目，所以我们开始有两个月的原型和概念验证解决，在这段时间中，Maria测试了Buildbot的各个方面来看它在将来的扩展性同时保持我们所需要的复杂构建的灵活性。我们知道我们希望构建系统尽可能的独立以便维护和调试更加容易。

阶段2:需求收集和开始实现

　　经过2个月的原型和概念设计阶段，我们相信我们选择的工具经过一定的开发以后能够应对我们的需求。项目的下一阶段需要对Buildbot和TeamCity进行一些功能比对，并初步尝试收集一些需求来进行TeamCity的替代。这个阶段比较难并且经过了一些返回，是因为1)仍然在学习和熟悉Buildbot的功能和限制，2)很难明确指出那些TeamCity的功能有必要，哪些没有。我们从最初的项目计划开始，一路上定期修正。并且在这个极端，我们也把ＩＴ部门加入进来评估构建一个完整的系统所需要的硬件资源。

阶段３：前端

　　我们使用的Buildbot版本（0.8.7）有一个UI，但是TeamCity的经验教育我们，这个UI几乎是不可用的，因为它没有办法应付我们构建配置和工程的数量。性能也是关心的重点。我们之前的经验告诉我们UI最重要的是可以快速加载，其他所有事情都是次要的。因此我们需要一个精通UI、设计敏锐的人来实现一个新的UI。我们招募了一个前端开发人员Simon，有高性能网站的经验。他负责给Buildbot一个新的前端表现。

阶段4：更多实现

　　这个阶段完成了大部分的功能实现。在发现需要基于Buildbot开发一些重要的功能来应付我们的需求后，我们一度重新评估项目进度，但总体来说，项目进展顺利。我们最后对我们的构建系统和测试框架（让所有测试输出标准化的XML，以便我们解析）做了一些功能上的开发。这一阶段的末期，我们吧一些内部项目（比如内部对Mono运行时和库的构建）从TeamCity迁移到Katana。这使得我们在真实的场景中获得用户反馈。从这开始，我们逐步开发更全面的功能集。

阶段5：生成准备和输出

　　这是在迁移Unity主要项目之前的倒计时阶段。我们使用Trello进行项目管理，它工作的很好，特别是末期项目的团队继续扩大（我们加入了另外一个团队成员—Daniel，我也开始Katana的开发工作并进行配置管理）。

现状

　　Katana 基于GPLv2 license在buildbot fork onGitHub上开源。我们还在继续开发，就在几周前，我们使用Autobahn部署了一个实时更新方案。我们现在对各个分支有一个非常好的构建状态总览。

　　并且有一个构建主机工作情况列表：

　　我们还可以查看一个具体构建或者测试的情况:

　　并且我们还有一个非常好的测试报告来帮助我们找到问题

　　Katana的结构越来越复杂，但是我们已经认识到哪些元素对我们最重要。架构现在看起来像这样：

总的来说，我们看到了如下的巨大改善：

l  可维护性

l  灵活性

l  可靠性

l  性能

总结：

　　总的来说，我认为Katana项目是一个巨大的成功，不仅是因为它对研发团队的帮助，还因为是它是一个利用开源力量的很好的榜样。我们为构建系统能够跟上研发团队的速度而感到自豪，我希望你们都能利用好自己工作室的构建自动化系统。