持续构建,持续集成,分布式构建

5ritest

构建服务器的硬件配置
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