微信号:infoqchina

介绍:有内容的技术社区媒体

跟Monty Taylor和Jim Blair聊OpenStack的持续集成与自动化测试

2014-08-06 17:40 InfoQ

OpenStack社区有一个CI和自动化测试小组,该小组为OpenStack社区的开发者们提供服务,而该服务所用的工具正是他们自己维护的一个OpenStack云环境。


对于这样一个囊括了十数个子项目,每月有300多位开发者提交代码的复杂项目,普通的CI系统是难以处理的。


我们跟该小组的负责人MontyTaylorJames Blair沟通,了解他们在构建和测试过程中所面临的挑战,以及他们是如何解决这些挑战的。


InfoQ:你们的CI系统每天处理多少次提交?你预计到Icehouse版本发布时会有多少?(注:本采访完成于201311月,当时距离Icehouse发布还有半年)

Monty印象中,我们的系统最高处理过每日400次提交。这些仅仅是通过测试的部分,实际上我们的测试量要大于这个数字,因为只有通过测试的代码才会进入CI


Jim每次提交被审查之后,我们在实施合并之前会再做一轮测试。


Monty对于每个被合并的提交,我们都会对其做8-10个不同的测试任务。因为测试会在上传的时候和合并之前各做一次,相当于每次变更我们都会跑将近20个测试任务。有一段时间我们的系统一天就跑了10000个任务。


GrizzlyHavana,我们的集成、测试量基本上增加了一倍。基本上每个新版本我们都会增加一倍的量,到Icehouse应该也是如此。


InfoQ:你们都跑哪些测试任务?

Jim首先是代码风格检测。因为我们的协作开发者人数众多,因此代码风格统一是非常重要的,我们需要确保大家都使用同样的编码方式。这是个很简单的任务,但很重要。


然后是单元测试,仅仅测试被变更的子项目,不考虑跟其他子模块之间有网络交互的情况。我们针对几个不同的平台做测试,包括2.62.73.3,基本上我们在CentOS上跑2.6,在Ubuntu上跑2.7


然后是集成测试。我们用DevStack将所有的组件安装起来,然后在安装起来的这个单节点云实例上跑不同的模板。不同的模板对不同的模块进行不同的设置,比如使用不同的数据库、不同的消息队列。可以选择的种类很多,不过基本上我们只测试那些常用的,比如MySQLPostgreSQLRabbitMQ这些。


Monty我们最近也在考虑引入ZeroMQ的测试。


Jim如果社区里认为某个子模块比较重要,使用的人也越来越多,也有更多的人愿意参与到debug工作当中,那我们也会将这个模块加入。


InfoQ:测试任务是由谁来写的?

Monty开发者自己写。我们的QA团队很小,基本上只关注测试系统本身的工作,不会有太多精力去关注测试任务本身。所以我们要求开发者自己提供单元测试和集成测试。


Jim我们最近在讨论的一个话题就是在这方面做更严格的限制,即只有写好了集成测试的变更提交才能够被接受。


Monty我们总觉得未经测试的变更就是有问题的。一般来说的确是这样。


Jim现在项目发展的这么快,有这么多组件,这里或那里的一个小错误可能就把整个系统搞死。


InfoQ:性能测试有在做吗?

Jim还没有,不过我觉得可能差不多可以启动了。我听说Boris Pavlovic正在做一个叫做Rally的测试系统,Joe Gordon则在进行一些可扩展性测试的工作——跟性能测试不太一样,不过关联比较大。这都是我们希望做的事情。


我们的测试显然没有覆盖所有的方面,不过我们最终希望测试所有的东西,当然这需要时间。


在本次发布周期内,我们关注于升级测试。现在我们已经在做一些,不过做的还不够,需要做更多。


InfoQ:在一个实例上运行一个测试任务大概需要多久?

Monty一般在20-40分钟,具体时间长短跟实例的配置有关。


Jim我们花了很多精力让测试变得并行化。我们构建了一个叫做Test Repository的框架,大多数单元测试在这个框架中已经可以并行处理,测试结果出的很快。


Monty还有Jim写的Zuul,这个工具可以一方面并行的测试成套的变更,同时又保持他们的测试顺序不变。


InfoQ:运行测试用到了多少机器?用于运行测试用例的实例配置是怎样的?

Monty我们自己是没有机器的。所有的测试都跑在公有云上,有些来自Rackspace,有些来自HP,都是赞助的。他们没找我们要钱,而我们需要多少就可以用多少。


Jim上一个版本周期内,最高的时候我们并行跑了340个实例,一个实例就是一个VM。集成测试一般使用很基础的VM——8GB内存,系统是UbuntuPrecise。我们把这个节点搞起来,然后让DevStack在这个VM上安装OpenStack


Monty实际情况要比这个复杂,不过大概意思就是这样。我们有一个nodepool用来管理这些VM,通过缓存来预备这些机器。我们需要将DevStack需要的依赖等东西都预先下载到本地,这样测试本身就可以离线运转。


Jim测试跑完之后,我们再销毁这些VM。实际创建的VM数量要比跑成功的测试数量多,因为Zuul的随机机制,有些时候它的测试跑到一半的时候才发现还需要一些其他东西,于是测试跑不下去了,我们会干掉这个VM,起一个新的。一个大致的比例是,如果一天跑10000个任务,那么启动的VM数量差不多在100000的量级。


InfoQ:可以认为用于OpenStackZuul模式是nvie git分支模式的一个改进吗?感觉Zuul似乎不适合分支过多的情况。

Monty实际上我们是不采用nvie git分支模式的,因为我们用了Gerrit,所以我们的代码提交模式跟Linux内核的模式更像:人们在邮件里交换补丁。我们的做法不是建立很多的分支然后做合并,而是让每一个变更形成一个虚拟的私有分支。相对于将每一次变更生成一个新的commit并增添至分支的顶端的做法,我们的做法是:在之前的一次修改之上再进行修改。我们的测试针对每一个独立的commit,而不是针对一个分支。


每一个开发者可以建立本地的分支,这些分支是私有的,没有什么发布机制。我并不知道Jim的笔记本上的分支是什么样的。我自己用git的方式比较奇葩,我不用分支,而是每次在我的master上重置ref——这是个非主流的用法,git新手最好还是不要这么尝试。


所以,OpenStackgit补丁流程其实是基于Gerrit的。


Jim另外,我们需要确保审查人员审查的对象是每一个commit(而不是分支)。理想状态下,每一个进入项目的commit都被人仔细的检查过。分支的话就会比较混乱。把每一个commit把关好,把好的commit合并,是比较精细的做法。


InfoQ:除了Zuul之外,你还提到了在Jenkins上使用Gearman来提高可扩展性,使用Logstashdebug,还有你上面提到的TestRepository将测试输出自动发给committer。目前的反馈机制是如何运转的?理想的情况是怎样的?

Monty反馈机制整体来说是越来越好的。你的问题涉及到几个方面。有关用Gearman来提高Jenkins的可扩展性这一点,首先Jenkins本身的设计是针对一个master的情况,让它支持多个节点是通过hack的方式来完成的。我们一开始的用法是跑一个Jenkins master和若干个slave,并行跑的测试任务数量要比正常的Jenkins用法要多很多。Jenkins在设计当中涉及到很多全局锁,所以要像我们这样用起来,会遇到很多可扩展性的问题。


更多精彩内容,请点击阅读原文。



 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 18个你可能不相信是用CSS制作出来的东西 手把手教你Spark&Mongodb『附源码下载』 你之所以看不见黑暗,是因为有人拼命把它挡在你看不到的地方 请把充电器请出卧室(百分之九十九的人不知道!) 这里有未来“互联网+”的十大趋势,客官你看可还靠谱?