51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【周活动】 找茬--心里圈的故事 !【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【108期】:我有自动化问题找joykao?双11剁手不吃土,来投稿赚回血红包! 【专题】用尽一切办法只为让你学好用例 自学软件测试那点事
查看: 3101|回复: 0

[转贴] 持续构建,持续集成,分布式构建

[复制链接]

该用户从未签到

发表于 2009-6-28 20:50:01 | 显示全部楼层 |阅读模式
构建服务器的硬件配置
elian  Question:
问下大家,你们对构建服务器的硬件配置都是怎么要求的??


laofo  Suggestion:
这个要看构建的项目了.


如果构建的项目很吃内存,那么内存就要很大
如果构建的项目需要很多的计算,那么CPU就要好


不过,如果公司的项目已经做成daily build了,相应的要求就可以降低,因为我们可以把daily build做到晚上去完成,只要保证第二天
早上有build可以给 tester/Dev就可以了.
---------------------------------------------------------------------
xiaoxiang7788:


其实构建是持续集成的一个重要组成部分。


    硬件要求嘛,要看项目来定,但一般情况下内存,CPU,硬盘读写速度这些都应该要最好的。


    如果只是简单的说构建与持续集成,那就等于是水滴与大海的关系,daily build是一只集成方式,但是持续集成比daily build
的好处就是可以尽快发现问题,尽早解决问题。


    其中daily build的一个缺点就是,对手工的依赖比较强(结合我们公司以前的经验来说),而且如果是团队的开发,也有了一个配置库做为
源码管理工具,那daily build对Developer的代码修改提交时间是有限制的,这点限制了集成的强大作用。


    再者,如果连续几天构建没有成功,而这几天之中Developer还在持续的提交修改的代码,那么等后面集成的时候会出现多少的问题应该是个未
知数吧。以我们公司项目以前的构建方式为例,几天(两天或者三天)没有成功的构建了,原因是每次构建都会出错(包括编译错,环境出错,测试环结的错误
等),这样就没有了集成的效果,做集成的目的不就是反应这个交付物的质量嘛。一个好的集成环境,就应该尽快尽早的让团队知道集成结果。


    放到晚上去构建的原因是不是因为构建时间比较长(之前我们的项目就是这样子的),如果是这样的话就可以考虑是不是可以使用分布式持续集成的方
式。
---------------------------------------------------------------------
laofo:
其实,发生了这种情况是有问题的.


    首先编译环境要让Dev自己去定义.当他们定义好了,自己安装完了,可以成功编译出一个build了,那么CM才拿着他们给的文档去搭建CM自
己的构建服务器.如果CM的构建服务器在按照文档编译build的时候出现了问题,要当一个Critical的问题发给研发人员,让他们去把服务器的文
档更新,然后 CM再搭建自己的构建服务器.直到CM搭建的服务器可以成功编译第一个build了,这才表明CM的构建服务器搭建成功了.这就保证了以
后的错误只能是 code的问题,而不能是构建服务器的问题了.


构建几天都没成功,这是一个很大很大的问题,CM要在项目会议的时候提出来,并且Project Manager要去跟踪这件事情.第一天没有成功,就
要找出原因,不能第二天再不成功.


---------------------------------------------------------------------
scmroad:


引用:
其中daily build的一个缺点就是,对手工的依赖比较强(结合我们公司以前的经验来说),


        不是很明白这句话.为什么daily build对手工的依赖比较强呢?做daily build其中很重要的一点就是把CM从每天手工做build
中解放出来.既然你都做到daily build了,为啥还对手工依赖比较强呢??


引用:    而且如果是团队的开发,也有了一个配置库做为源码管理工具,那dailybuild对Developer的代码修改提交时间是有限制的,
这点限制了集成的强大作用。


这一点也不是很明白,为啥daily build会对Dev的代码修改提交时间有限制呢???我真的不是很明白.假设你们开发的项目很大,需要8个小时
才能作出一个build,如果你让 daily build每天的晚上12点开始build,那么早上8点,大家上班来也可以得到一个build了,何
况现在大部分都是早9点上班.难道你们公司每天晚上 12点以后还有人check in 代码么?


---------------------------------------------------------------------
Zealic:
构建应该使用尽可能小的代码变更
便于排查问题


提交时间的限制实际上是鼓励频繁的提交。如果不是 C++ 这样构建时间很慢的项目,一般提交代码后几分钟内就可以得到结果,通过单元测试、自动化脚本
和工具进行一系列检测,从很大程度上可以控制提交代码的质量。


如果是非密集型提交,比如一周只提交了一次代码,那么变更代码可能设计千行以上。这是不利于排查问题和回溯代码的,因为更多的代码意味着更多问题的集中
变更,代码交叉影响的几率也更高。


daily build 实际上可以认为是一次完整的 build,因为我们项目可以分为很多子项目,子项目的 build 不需要互相影响。可以在
daily build 中做整个项目的集成测试以及耗时很长的但不要求即时反馈的测试。


此外 daily build 还可以保证在夜间的构建是一个非频繁性更改的构建,便于提交给测试人员在第二天进行测试,而不是白天频繁构建中的残次
品,因为在开发人员下班前,一般都会要求尽可能签入稳定的代码。


---------------------------------------------------------------------
i子休:
手头有一个例子比较能说明问题,我们有一个嵌入式系统要在10个平台上编译


之前用的是“双核8CPU”的服务器,没办法并行编译,Daily Build大概要6个小时


后来换成“8核双CPU”的服务器,10个平台并行编译,Daily Build只需要不到1小时的时间


另外,C++的编译和C的编译比起来,需要更快的CPU,没做过其他语言的产品……


分布式构建对于工具的依赖性很强,不一定适合每个项目


目前比较成熟的分布式构建工具中


distcc - 只适用于gcc,扩展到其他编译器有些困难
dmake - Sun的,需要完全修改现有的Makefile语法
clearmake - IBM的,基于Makefile但要安装ClearCase和MVFS
emake - Electric Cloud的,基于Makefile但要安装EFS


前两项是免费的,后两项相当贵。


有些公司有自己编写的分布式构建工具,但我比较怀疑可扩展性如何…


---------------------------------------------------------------------
scmroad:
对头。


关于持续集成里边什么时候做测试,怎么做测试,都做什么样的测试,连持续集成的创始人Matin Flower都不是一次想清楚的,在他那边著名的文章
里,第二版的内容也对第一版的内容做了修改,提到了很重要的一点,不要求在一次集成做完所有的测试,因为如果所有的测试仅仅需要很少的时间还可以忍受,
太多的测试反馈的速度就太慢了。他也说要针对不同的构建有不同的测试量。具体可以参考那篇文章。


配置管理工程师(CM)应该尽快的给开发人员以反馈,从而提高提交代码的质量。


另外,测试人员肯定不能拿每天中间的build去测试,只需要拿昨天晚上发布的那个build就可以了,也就是为什么一定要让开发人员保证每天的
daily build都是没有error的,如果连续两天都没有成功的构建,可以说在这一点上是有很大很大的问题的。


---------------------------------------------------------------------
xiaoxiang7788:
第一: 你说的这个情况是在首次搭建持续集成环境的时候的状况, 无可厚非.  但是一个持续集成环境你能保证在一个项目中是一成不变的吗? 能保证集
成服务器一直都运转良好吗? 还保证一个团队里面每个人都对持续集成有这么深的了解吗?(如果是一个大的开发团队) 所以个人认为, 以上这些(当然还
包括我没想到的, 要看具体项目)都应该在做持续集成的一开始就考虑进去.


第二: 几天没有成功的构建, 这种情况还是有很大可能发生的, 特别是在国内的公司. 比如, 有一个大的开发团队, 可以分为十个小组, 某个小组
修改了一个类中的方法, 而其它九个小组都有人在调用这个方法, 这个时候可能就会有包括沟通交流导致的延时, 小组办事效率的延时等(还要考虑到如果
是新人接手一个老员工后, 对代码的熟悉程度). 等所有人都修改好了这些类, 所有人都提交了. 下一次构建才可以完成, 而在修改的过程中, 能保
证其它人不去check in代码吗? Developer check in的代码他们自己做的测试是没有问题的. 能保证集成编译, 运行功能测试
等阶段不会出问题吗?


当然这只是一个假设, 但是我在项目集成过程中遇到过好几次几天不会构建成功, 导致这个情况的产生可能是Developer对持续集成的重视程度不
够, 也可能是持续集成服务器的崩溃等. 遇到这个问题的时候对于CM来说也是一个相当大的考验, 因为你要去考虑怎么样去避免这些问题的产生。


---------------------------------------------------------------------
xiaoxiang7788:
刚才在上面说明了,daily build应该理解为定时构建。如果一项目build时间真的需要8个小时的话(window等特大型项目除外),就
应该考虑一下分布式集成啦,不然8个小时就失去了持续集成的意义,持续集成是要尽早尽快的反馈结果。
    假设一个项目的构建时间并不是8小时,而是1或者2个小时,你会愿意把build时间放到晚上12每天只去集成一次吗?集成的工作量是与两次集
成间隔时间的平方成正比的。尽管我们还没有具体的衡量数据,但是可以大概估计出来:每周集成一次所需的工作量绝对不是每天集成的5倍,而是大约25倍。
比如我们给daily build(定时构建)定一个loop,构建所需时间为2个小时,每天的12:00,15:00,18:00,03:00定时执
行构建,那么在这一种情况下是不是对Developer的code提交时间在所限制呢?如:CM人员会对Developer说:我们15:00开始要
build啦,把你们要提交的code尽快提交,会不会形成这样一个不好的习惯?


---------------------------------------------------------------------
xiaoxiang7788:
回复 7# Zealic 的帖子
说的非常好,我顶。
体现了持续集成的必要条件,就是尽早尽快的反馈集成结果。而你在这里所说的daily build我可不可以认为是利用晚上的时候做一次干净构建,平时
所做的是增量构建呢?现在我们公司也在做这样的事情,平时就是日常的持续集成,利用晚上的时间做一次干净构建。期待指教.......


回复 22# i子休 的帖子
持续构建可以认为是经过一系列的过程得到一个可交付物,而对于可交付物的质量是怎么样,它不是特别的关心。而持续集成则是强调测试(即验证可交付物的质
量)这一部分,正是因为持续集成强调了测试这个环节,即验证这个可交付物的质量如何。所以如果你的项目没有把单元测试和功能测试等,就还没有到持续集成
的必要,只需要build就可以了。
  如果随着项目的扩大,如果经过集成得到了可交付物,那就可以认为build成功,但是如果交付物的质量没有通过验证,那我们就可以认为这是一次集成
失败;只有两个全部成功后才可以说是一次成功的集成。所以也就可以说持续构建是持续集成的重要组成部分,而不是同一个概念。
   如果你的build除了完成编译,打包的功能外,还可以完成测试、部署,就可以认为你已经在做持续集成了,而不单单是持续构建了。
---------------------------------------------------------------------

---------------------------------------------------------------------
上面的内容来自论坛的一个精彩的帖子,整理了一下.感兴趣的可以到下面的帖子来和大家交流.
http://bbs.scmroad.com/viewthrea ... p;extra=&page=3

感谢elian提出这么好的一个问题.
---------------------------------------------------------------------

软件配置管理(CN) Google讨论组.如果想和大家交流,请发送email到
ConfigMgmt-CN@googlegroups.com
更多的信息,请浏览讨论组主页
http://groups.google.com/group/ConfigMgmt-CN?hl=zh-CN
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /2 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2019-11-18 02:34 , Processed in 0.062184 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2019 Comsenz Inc.

快速回复 返回顶部 返回列表