跌跌撞撞的持续集成之路

发表于:2009-9-09 14:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:仝键    来源:51Testing软件测试网采编

#
敏捷
分享:

  “天下事头绪纠缠,兴一利必也生一弊。”

  一句话,道破了改进难点所在。最近在项目中围绕持续集成做改进的时候,对这一点感受颇深。跌跌撞撞的一路走来。我们的持续集成的过程已经变得有些“个性化”,反过头来看我们一路的变化,非常有意思。

  从项目的技术架构说起,我们的项目是采用的J2EE+Flex的方式进行开发的。在我进入项目组的时候,一个比较健壮的持续集成环境已经搭好了。工程分为两个,一个是Java后端的工程,一个是Flex前端的。我们的持续集成服务器是CC。整个开发工作是围绕着持续集成展开的。一周为一个迭代。

  那个时候,我们采用的是比较标准的方式:

  * 后台采取TDD的方式开发。

  * 每次提交代码之前更新所有代码,然后运行所有测试用例,全部为绿色的时候才提交。

  * 前台Flex比较麻烦,所以采取了用功能测试覆盖单元测试的方式。用基于Ruby的FunFx写单元测试。工作方式与后台差不多,每次前台功能测试全部通过了才提交。

  * 持续集成的流程是每隔5分钟检测一边代码库,有更新就build。

  * build的流程是先编译后台,跑单元测试,单元测试通过了,再编译Flex,将swf和html以及后台的文件打成war包,部署到tomcat上去,跑功能测试。

  * build成功之后发布到特定的目录,形成发布列表。有war包供人下载。

  那个时候,build一次大概是15分钟,因为Check In Gate环节是按照标准流程走的,所以build出错的几率也小。CC大多数时候是绿的。哪怕偶尔出问题红了,也很快被修正了。

  随着项目的开发,代码规模越来越庞大。功能测试越来越慢,比起自动执行脚本那种速度,开发人员更乐意手动点两下,加之上面对工作进度的压力。更改了一些工作方式:

  * 后台的工作方式不变。

  * 前台,将功能测试脚本的工作交给几个测试人员编写。几个测试人员也坐在附近,基本可以看作团队成员(到后来编制也是我们团队的成员了)。 开发人员人肉测试一下保证没有问题了再提交。

  * 测试人员写脚本的流程是拿到上一次build成功的war包,在本地写脚本,本地测通过了再提交。

  * 持续集成服务器上功能测试不通过的时候,由测试人员提交BUG,开发人员修改。

  * 持续集成的流程依旧。

  这样,从后来收集的数据看,工作效率是提升了,因为参照以前的统计,开发人员的工作一下减轻了1/3。以进度来衡量的速度自然很轻易就可以让上级满意了。

  新的解决方案总会产生新的问题,测试人员在测试方面的专业性,使得他们写出来的脚本测的更细。功能测试的时间占耗,增长的更快了,短短半个月,就增长到了1个小时。每当出现问题,作出反应之后,要在1个多小时以后才能知道结果。而且,持续集成方面并没有做到,一旦出错,谁也不能提交代码这么严格。模块化的设计所带来的假想的安全感和进度的压力,使得开发人员修正问题的激励不高。于是修正问题的速度不如产生问题的速度快。持续集成服务器在那两个个礼拜里只有两头是绿的,周一早晨和周五下午。

  最早,我们发觉,由开发人员重构造成的脚本失败占大多数,而测试人员每次拿到的上一个版本是没有错误的。所以会出现自动化脚本本地跑得过,服务器上跑不过的情况发生。于是我们修改了发布的逻辑,在后台单元测试通过、flash编译完成的情况下打的那个war包,复制一份,放到某特定目录指定为 current build。供测试人员写测脚本使用。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号