BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

跌跌撞撞的持续集成之路

| 作者 仝键 关注 0 他的粉丝 发布于 2008年9月19日. 估计阅读时间: 14 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
“天下事头绪纠缠,兴一利必也生一弊。”

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

从项目的技术架构说起,我们的项目是采用的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。供测试人员写测脚本使用。

过程改进之后,测试人员可以快速的修正脚本了,虽然对于开发人员重构造成测试人员工作的返工无疑是一种浪费,但是毕竟自动化的测试省了回归测试的不少时间,还是可以接受。

脚本的修正速度解决之后,工作似乎有了些起色,但很快,问题的本质就暴露了出来--build的时间太长了,修得速度还是跟不上问题产生的速度。尤其是中间缺少当build失败时强制阻止代码提交的环节。这之后依然是周一和周五两头绿,中间都是红的。于是,我们觉得问题还是出在build速度上。我们人工的将功能测试脚本分到四个suite里去,然后以多线程的方式运行。速度被提高了4倍。于是又消停了两天。

好景不长,多线程的测试似乎不太稳定。很多本地可以跑通的测试用例,到了服务器上就失败。险些一个礼拜都没有build出一个版本。最后不得不改回单线程。这时,build一次已经占到了100分钟。第一期的产品Backlog还没有完成1/3。

持续集成走到这里已经进入一个困境,有必要做一些更深一步的改进。经过多次讨论,归纳出了几套方案:

  • 分冒烟测试和all test两套测试用例集是我们当中呼声最高的一种方案,当我的代码提交之后在跑完所有单元测试和基本的冒烟测试之后就发布beta版,由测试人员接到beta版,进行更细致的自动化测试并带一些人肉测试。但是反对的声音认为,不跑完全部的测试用例就失去了持续集成的意义。而且会更降低开发人员修正 Bug的积极性。于是作为修正,支持的声音则提出,在Check-In Gate处把关,恢复每个人提交代码之前跑测试用例的实践。可这明显会给开发人员带来更大的工作负担,估计以此时的进度压力,开发人员的安全感肯定会大幅下降。很可能会推行不下去。
  • 另一个方案是从细节处调优,把WEB应用部署到另外一台机器上去,或许就会稳定一些了。但是反对的声音认为,以测试用例的这个增长速度,他早晚会不稳定的,而且可能撑不过两周。作为修正,想考虑分布式,但是我们所有人的知识储备中,并没有一个人清楚CC有没有分布式能力。所以想的是购买Cruise,但是价格的障碍就摆在眼前了,在项目前景还不是很明朗的情况下,估计很难申请到资金,但也不是不可能,只要我们敢于冒这个风险。
  • 第三,便是更为高级的分支式开发,将版本库划分一下分支,以分支来搭配持续集成,以分支合并来触发自动构建。这样做,开发的过程就更加有板有眼,粒度可以划分的更细。可是分支的划分,一时想不清楚。但是假设想清楚了,似乎这也使得我们的工作流程更加复杂了,做如此之大的改变,风险有多大?效果有多大?成本有多大?到底是值不值得?一时也想不清楚。

方案有了,听起来都很有道理,也都有问题。该如何做出决策,是个问题。现在大家众说纷纭,都有理,就变得难以抉择。而且到现在了是不能随便尝试的,这种尝试也是一种风险,一旦出问题造成的成本上升都会加大我们身上的压力。

迷茫之下到AgileChina上跟大家讨论了一下。非常高兴的收集到了几方面的建议:

Jeff Xiong觉得可以将测试分级,并将build分为两个环节,一个跑基本的用例,一个跑全部的用例。这跟我们的第一套方案的思路吻合。但是这种行为是不是失去了持续集成的意义呢?他也不是很确定,他说:

我也不确定……不过,不全面的持续集成至少比不能用的持续集成要好。哪怕一个quick build(只?)能抓到80%(70%?60%?50%?)的defect,如果它只要很少的时间就能跑一遍,似乎值得这样做。

不过同时就需要(可能是专门的)人来关注slow build的健康状况,不然broken functional tests可能被忽视并累积。

因为是在论坛上,互相之间的交流容易造成理解上的偏差,我便阐述了一下我的理解:

嗯。。。也就是说分一个fast build和一个slow build然后有专人关注slow build。

那我的理解,这个fast build应该是反映了后台的健康和前台与后台的基本集成的健康。主要用来完成保障集成的角色。

而slow build则是反映了从用户接口来看的软件的健康状况,定期回归,防止发生过的错误再次发生。

这样逻辑上看着很清晰,但是两者之间的同步。。。会不会有什么问题呢?

Jeff Xiong认可了我的理解,并提出了更进一步的解释和建议:

slow build实际上是运行完整的回归测试套件。当然理想的情况是slow build基本上不出错,因为*逻辑*用单元测试都覆盖到了,功能测试只是在描述*表现形式*。那么因为slow build基本上不出错,就没有价值每次都去运行它,让它在后台慢慢的跑着,过一段时间(半天或者两小时)去关注它一下,没问题就好,偶尔出了问题就马上解决并且加上对应的单元测试。这样你既节约了时间又不会严重降低对质量的保障力度。

实际上的情况可能比较难这样理想,但是和所有好的环境一样,这个环境不是说一下子规划好就万事大吉的。你可能大概的分一分,然后不断的维护,在两组build之间交换测试案例,一些覆盖到大量功能的、经常出错的案例也许要换到fast build的冒烟套件里面,一些看起来永远不会出错的案例也许可以换到slow build去。一直琢磨这个事,它才会变得越来越好。

(题外话:最近我觉得稍微大一点的项目应该有比较专注的build master,developers往往并不是特别认真的考虑build和CI的持续改进。)

而胡凯则提出了一些基于CC采用分布式的解决思路:

CruiseControl是支持一个叫做Distribute的Contrib,它的Idea是:因为CruisControl支持叫做Composite的build方式,那么你可以起多个build server一起来build同一个项目,当且仅当所有的子build通过,整个build才算成功。

对于每个build server,你是在单线程测试,对于整个项目,你却是并发测试,因为有多个server同时在跑测试。

但是他也说到CC毕竟是开源的东西,配置起来十分麻烦,于是最后也提出了采用Cruise的方案^_^:

或者你也可以尝试一下ThoughtWorks新发布的Cruise, 基本的理念很相似, 都是把测试分布到不同的机器上执行。

在试用期内可以同时跑6个Agent.你可以在每个Agent上执行不同的Target比如

Agent1 : ant ft.suite.1
Agent2 : ant ft.suite.2
Agent3 : ant ft.suite.3

你可以拿来玩儿下,根Open Source的那个比起来,应该容易设置很多。

缺点是:
  • 你必须使用 hg或者svn 作为 SCM
  • 试用期过后,你只有2个免费的Agent

另外,糖醋鼻子还提到了分支式开发,大家围绕这个还展开了激烈的讨论,不过我考虑到分支式开发对我们的利可能要远小于弊,最终还是放弃了这个方案。

在吸取了两方面的建议之后,经过一番思考,决定开始两方面的准备,一方面,对测试用例的分级方面做了一些工作,重构了一部分用例的结构。另一方面我去调研分布式构建的实现手法。CC的配置果然非常麻烦,调研期间发现了有RemoteAnt这个东西,试了一下基本满足我们的需求,考虑到一个Agent不用做的太过重型,于是就采用了这个方法。在分布式的技术调研已经完成的情况下,测试分级要不要做成了一个问题,但考虑到目前需求只作了1/3,如果这个都抗不住要分级的话,后面的工作就没法做了,所以分级的事情,虽然做了,但是也暂缓实行。

现在实践已经采用,会不会产生新的问题呢?前文说过“兴一利必也生一弊”,这个事情是肯定的。那么问题就来了,既然弊端肯定会滋生,我们怎么知道作出的决策是正确的呢?

其实,倒回去看这一路走来的过程,除了一个可以运行的过程以外,还有一个很重要的收获,那就是:如何进行决策。而所谓决策,并不是在黑白分明的事情之间做出选择,而是在都有理的事情中做出选择。就像我们都知道做软件设计的时候,设计是没有好坏之分的,只有适不适应你的具体情况之别。所以当我们面临几套解决方案的时候,就好象面对几套设计方案一样,真的是很难选择。如何做?各自就有各自的思路了。像我们就吸收了敏捷开发的思想中所强调得不做过度设计。选择立杆见影的改进去做。同时,像前文所说,抱着拥抱变化的态度,相信兴一利必生一弊并不是坏事。相反,他可以从一定程度上,带领我们找到真正的问题。

作者简介:仝键,网名咖啡屋的鼠标,06年大学毕业,普通程序员,专注于Java、Flex方面的开发、Agile等软件开发方法论的学习。爱好参加社区活动。


志愿参与InfoQ中文站内容建设,请邮件至editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

InfoQ能否加一个功能 by Lee R

就是统计每篇文章的阅读次数,然后根据阅读次数做每周推荐,或者是每月推荐,现在很多网站都有的

学习微软经验:超大规模的 SQL Server build 系统 by Zhang Charlie

微软中国研发集团服务器与开发工具事业部SQL中国研发中心博客:




SQL Server Build 系统(刘春雨 SQL Server中国build团队,2008-7-28)




先提两个问题:



1)如此成功的超大规模 build,微软是如何做到的?有什么杀手锏吗?



2)微软这么做,是不是敏捷?是敏捷,还是卓越?敏捷好,还是卓越好?




中西合璧的敏捷 OO 教练 张恂


www.zhangxun.com

CC 2.7.x 支持比它的DistributedContrib更建单的分布式 by Li Guanglei

cruisecontrol.sourceforge.net/buildgrid.html

一句话总结就是在多台机器上构建, 而把结果汇总到一个页面

想省钱的话何必死抱着CC by Li Guanglei

Hudson不也不错

Re: InfoQ能否加一个功能 by 刘 申

谢谢您给我们提的建议!这些功能已经在开发当众,将会在我们的下一个版本中实现:)

而我们现在的做法是,每周通过我们的Newsletter(我们管他叫“每周精要”)向大家推荐本周的妙文;每个月,通过我们的电子期刊(将于下个月发布)向大家推荐这个月的精彩文章:)

同感,InfoQ 的 useability 有待改进 by Zhang Charlie

一年之前我也曾经提出过许多类似的建议。可是遗憾,至今好像没什么动静。



个人觉得,尽管英文版的内容很好,但 InfoQ 离真正的 2.0 社区还距离很远,现在顶多 1.5。

Re: 同感,InfoQ 的 useability 有待改进 by 霍 泰稳

不要着急,这个功能已经指日可待了:) 而且还会增加评论邮件提醒功能,即你参与评论的内容,如果其他人有回复,会通过邮件给你发送通知。我们的开发团队人员稀少,backlog上的功能一大堆要实现,所以动作慢了一些,大家多担待。

Re: 学习微软经验:超大规模的 SQL Server build 系统 by wang yi

偶不是ms的人也知道,SQL Server 这种规模的项目怎么可能用敏捷,找死吗。

Re: 学习微软经验:超大规模的 SQL Server build 系统 by han isaac

大规模的项目用敏捷就是“找死”?怪哉~

仝键,你们为什么不用 Branch-Merge? by Zhang Charlie


仝键:另外,糖醋鼻子还提到了分支式开发,大家围绕这个还展开了激烈的讨论,不过我考虑到分支式开发对我们的利可能要远小于弊,最终还是放弃了这个方案。


为什么 Branch-Merge 对你们会弊大于利,你没有说明。问题可能恰恰出在这里。





刘春雨介绍了微软是如何解决这个问题的:




我们每天做这么多的build正体现了我们如何支持整个SQL Server工程体系和构架:




在SQL Server 2008的工程体系和构架中,我们将每个需要增加或增强的功能特性做成一个单独的分支,在这个功能特性开发和测试完成后,其代码才会合并到SQL Server的主线代码中 ... 每个分支都需要build来进行及时的测试,因此有了这个我们当前每周需要的build个数——130。当build结束后,Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准。最后当这个功能特性开发和测试完成后,其代码将会融入到SQL Server的主线代码中,然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码,来保证和主线代码的同步。




相关数据:




每个build 的大小在300GB左右。


每个完整的build需要几十台高端的服务器运行2.5天。


每个完整的build由几千个job、10000多个参数组成。


我们每天同时做20个左右的build,每周130个。


位于美国微软总部雷蒙德和北京的build团队能够保证build全天24小时不间断的顺利进行。


从去年至今,我们build team已经成功而准时地完成了数以千计的build。




很高兴看到刘春雨的这段介绍,它们和十年前张恂从《微软的秘密》中所学到的方法是一致的。这说明过去十多年来微软一直在沿用这套成熟的方法,它们当然是软件工程中的 Best Practice。正是受到微软经验的启发,张恂带领的研发团队早在 2000 年和 CMM 热之前就做到了软件配置管理和 Branch-Merge,领先于当时国内软件同行业的水平。




你们的系统规模不可能比 SQL Server 更大吧?对于如此庞大系统的功能开发和质量保证,微软运用 Branch-Merge 显然是非常成功的。我觉得你们应该跳出“极限敏捷”和 CI 的圈子,试一试其他成熟的“敏捷”方法。




中西合璧的敏捷 OO 教练


www.zhangxun.com

系统过大,该考虑分解为几个应用了 by He Yongshi

可以把系统分解开,变成几个子工程,分别构建,只要协调好引用关系,分配好时间片,应该能把速度提高。

Re: 仝键,你们为什么不用 Branch-Merge? by zou jasson

张敏捷又来做广告了!!!

怪了,这也算广告??? by Zhang Charlie

2008年9月22日 上午1时41分 发表人 jasson zou:



张敏捷又来做广告了!!!




契合主题,张恂分享了自己的一些经验和成果,这也算广告?



就算是广告(广而告之),张恂的每一篇文章、每一次评论都可以算广告,这有什么不对吗?InfoQ 英文版、中文版的每个页面上到处是广告,你没看见?



没必要大惊小怪的。

Re: 怪了,这也算广告??? by Lai Jason

怎么不算广告?你这是隐性软广告,InfoQ 最不做的就是这类。没错这个页面是有广告,数量也不少,但也是别人掏钱或者合作做的。这样吧,你给 InfoQ 掏点广告费,价格合理的话,肯定会给你一个好的 package,如何?

Re: 怪了,这也算广告??? by Jacky Li

选择更加适合自己团队的运作方式 by wei Kent

看了文章,感觉该作者最初犯了点教条主义的错误:无论现实如何,既然持续集成要集成,一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可,都是在错误认识的基础上做的错误判断。

持续集成的基本的本意很简单,就是减少集成的成本,基本本质无非就是控制项目成本。所以采用什么集成方式,判断的唯一标准是成本(当然是指在某个质量底限下的成本)。
手段无非有三,通过如下手段综合考虑:
一、增加持续集成服务器投入;
二、增加build 人手投入,大的team甚至可以由一个build master带领一个“分布式"的team;
三、选定合理的集成周期,是real-time build 还是daily build;
如果你的项目很大,销售额也大,build的时间长,意味着你要选择一和二是比较合理的,因为客户得罪不得。
如果你的项目很大,build的时间长,销售额一般,则调整一和三比较合理,这些投入成本较好控制。
如果你的项目大,build的时间长,销售额很少,那么唯一的选择恐怕就是daily build.(实质是牺牲一定的质量)。

你的team情况看来,测试人员到位,build master也比较成熟,那么剩下就是看看项目销售额了:
销售额大,客户比较重要,那么选择增加集成服务器投入;反之,则可以让unit test 实现real-time build, 验收测试实现daily build(每天晚上跑一次或者两次,根据你要支持的浏览器来定).
如果unit test都难以实现real-time build,说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。
如果依然无法实现real-time unit test build,那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。

Re: 选择更加适合自己团队的运作方式 by wei Kent

看了文章,感觉该作者最初犯了点教条主义的错误:无论现实如何,既然持续集成要集成,一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可,都是在错误认识的基础上做的错误判断。



持续集成的基本的本意很简单,就是减少集成的成本,基本本质无非就是控制项目成本。所以采用什么集成方式,判断的唯一标准是成本(当然是指在某个质量底限下的成本)。



手段无非有三,综合考虑:

  • 一、增加持续集成服务器投入;

  • 二、增加build 人手投入,大的team甚至可以由一个build master带领一个“分布式"的team;

  • 三、选定合理的集成周期,是real-time build 还是daily build;



  • 如果你的项目很大,销售额也大,build的时间长,意味着你要选择一和二是比较合理的,因为客户得罪不得。


    如果你的项目很大,build的时间长,销售额一般,则调整一和三比较合理,这些投入成本较好控制。


    如果你的项目大,build的时间长,销售额很少,那么唯一的选择恐怕就是daily build.(实质是牺牲一定的质量)。



    你的team情况看来,测试人员到位,build master也比较成熟,那么剩下就是看看项目销售额了:


  • 销售额大,客户比较重要,那么选择增加集成服务器投入;

  • 反之,则可以让unit test 实现real-time build, 验收测试实现daily build(每天晚上跑一次或者两次,根据你要支持的浏览器来定).

  • 如果unit test都难以实现real-time build,说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。

  • 如果依然无法实现real-time unit test build,那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。
  • 分析的不错,赞成! by Zhang Charlie

    搞软件工程,一定不能教条、先入为主,要算算投入/产出比。

    2008年9月23日 下午8时56分 发表人 Kent wei



    选择更加适合自己团队的运作方式



    看了文章,感觉该作者最初犯了点教条主义的错误:无论现实如何,既然持续集成要集成,一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可,都是在错误认识的基础上做的错误判断。




    ...

    解决手段的分析有点问题 by Zhang Charlie

    kent wei 推荐的三种手段不错,但推荐的理由和情况分析有点问题,存在漏洞。




    如果你的项目大,build的时间长,销售额很少,那么唯一的选择恐怕就是daily build.(实质是牺牲一定的质量)。


    Daily Build 是一个著名的微软实践,而微软的项目大,build 时间也长,销售额应该也不少,更不会去牺牲质量。



    如何选择这三种解决手段,真的和项目销售额有关吗?好像没说清楚。

    做媒体的不可以这样无耻! by Zhang Charlie

    2008年9月23日 上午7时49分 发表人 Jason Lai



    怎么不算广告?你这是隐性软广告,<strong>InfoQ 最不做的就是这类</strong>。没错这个页面是有广告,数量也不少,<strong>但也是别人掏钱或者合作做的</strong>。这样吧,你给 InfoQ 掏点广告费,价格合理的话,肯定会给你一个好的 package,如何?


    什么是隐性软广告,你能不能给出一个科学的定义?是不是软广告,也不是由你说了算吧。




    你们采访熊节、潘加宇、温昱 ... 有没有收费?算不算软广告?Ok,你可以说他们是合作伙伴,如果认定为合作,就可以免费。那么,合作不合作,岂不是由你说了算?你高兴,就算合作,可以免费;你不高兴,就算非合作,要收费。做媒体的不能这样无耻吧。




    你知道什么是平等、人权和言论自由吗?什么是你的价值观?难道被铜臭味儿和所谓的哥们儿“义气”蒙住了双眼?




    一个知名技术社区和论坛的编辑如此公开地向发表合法评论的网友要钱的,张恂记忆中好像还是头一回遇到,即便在 CSDN 上好像也没有出现过。




    Jason Lai,作为 InfoQ 主管和主创人员,你应该向张恂和所有的 InfoQ China 网友道歉!




    中西合璧的敏捷 OO 教练 张恂


    www.zhangxun.com

    Re: 分析的不错,赞成! by wei Kent

    <block> 搞软件工程,一定不能教条、先入为主,要算算投入/产出比。 </block>


    这里只是讨论持续集成实践,和哪种方法学不搭边。投入产出是所有开发方法学需要解决的问题,不仅仅是软件工程需要解决的问题。


    实际上,持续集成在敏捷XP中实施会更好,因为XP强调pair programming,这样的持续集成更有意义. 错误的理解需求和错误的测试,无非就是集成出错误的结果. 所以持续评审可以强化持续集成的效果.



    <block>Daily Build 是一个著名的微软实践,而微软的项目大,build 时间也长,销售额应该也不少,更不会去牺牲质量。如何选择这三种解决手段,真的和项目销售额有关吗?好像没说清楚。</block>


    所以微软的东西那么多补丁. 如果一个普通的商业项目有微软那么多严重漏洞,这公司早被咔嚓了,那是垄断的话题了。而且还牵扯到产品领域开发和项目领域开发的不同。


    daily build不是微软创造,也不是因为微软而著名。


    我说销售额只是一个直观的判断,实质上是看效益。

    Re: 做媒体的不可以这样无耻! by Chang Kaishen

    在 InfoQ 冷眼旁观潜水很久了,今天看到楼上极品大叔一直在跳梁,实在忍不住了。

    大叔之前在各个网站的所作所为,我是略有耳闻,原来以为嘴皮子仗是圈内常事,也不以为然。不过有幸看了几次大叔因为右脸一被摸就轰然倒在地上滚泥巴,大声哭喊自己下巴被打脱臼的荒唐喜剧,一直觉得忍俊不禁。我挺纳闷,为啥其他国内热门的软件社区和讨论组,就一直没有张大叔的身影呢?JavaEye?CSDN?AgileChina?Scrum 讨论组?甚至前几天上海的 Scrum gathering 活动?张大叔不是在上海么?怎么从来没听说过?我邪恶地想了想,应该是因为大叔已经把自己四处踢馆吵架,已经散播得臭名远扬了。InfoQ 这边是不是都不删贴的?每次一看见这个极品大叔过来这边搅浑水,以及他不断变换给自己贴金的签名,我感觉跟我杯子里面飞进苍蝇一样恶心。

    InfoQ 为什么还留着这样恬不知耻的人在这里到处跳梁?一定要等到哪一天人都被他恶心干净了才知道该做些什么了?

    Re: 做媒体的不可以这样无耻! by 熊 小

    个体临床表现为自尊受损,在自尊受到威胁时,常常反应强烈。
    www.hrxl.cn/rengezhangai/renge_3053.html

    我觉得还没有影响到您的自尊吧?很有威胁么,就反应这么强烈了?

    对,要看效益 by Zhang Charlie


    2008年9月24日 上午1时2分 发表人 Kent wei




    我说销售额只是一个直观的判断,实质上是看效益。


    对,要看 CI 的投入/产出(效益)。



    在本案中,如果投入 CI 的代价很大,效果又不好(损失了开发效率),甚至得不偿失,那么就应该放弃 CI,试试 Branching-NI(Nightly Integration)。在这点上,我们的看法基本上是一致的。

    Re: 做媒体的不可以这样无耻! by Chang Kaishen

    好笑。我怎么看不出公开要钱?人家只是建议你如果要投真正意义上的广告,你可以掏钱吧?逻辑都搞不清楚,就在这里混淆概念。

    Re: 做教练的不可以这样不注意身体!!! by 熊 小

    建议您别在InfoQ这里浪费您的宝贵时间了,原因有四:
    1、您赶紧去找个诊所看看病,别等发展严重了,那可是中国IT界的一大憾事。对您来说,身体是忽悠,啊不对,是教练的本钱。其实我觉得您身体可能还成,就是这脑子……难道您是因为业务发展得太蓬勃了,没工夫?那怎么还有时间在这里混?要不我心理小小阴暗一下,是不是因为诊疗费上有困难?是不是因为您的事务所门可罗雀?没关系,我相信InfoQ肯定好人做到底,既然能看出来您的问题,再帮您报销个医药费,又怕什么的?到时候您记得把发票拿给霍泰稳报销,不过千万看清楚,别把超市买手绢的小票拿过来。
    2、如果您还指望用这种几乎可算是超级无敌掌门独有的方式暴得大名,那么恭喜,您已经达到目的了。出名有两种方式:骂名人,抱粗腿。您怎么出的,人所共知。
    3、您在这里东一榔头西一棒槌的,即使自己无所谓,也浪费广大网友的宝贵时间。不过话又说回来了,“存在即是合理”,您能给广大网友在繁忙工作之余找个乐子,斗个闷子,也算不错。不过在此提醒广大网友:“看戏有风险,时间须谨慎。”
    4、您得空也歇歇,嘬口水,嘴里边总横着个东西也挺累的,再说也得喘喘气嘛,要不还不得热死……

    Re: 做媒体的不可以这样无耻! by Mak Steven

    看到閣下有關 "平等、人权和言论自由" 的論述感到十分惡心.


    情況有如自己拍短片寄去CCTV要求全國廣播. 給人拒絕之後還惡人先告狀~


    希望尊重InfoQ.com的編輯權以及其保障付出真金白銀的廣告客戶的權利, 以及對廣告及內容詮釋權利.

    张恂将提供本案的详细案例分析 by Zhang Charlie

    请见:www.zhangxun.com/?sname=InfoQCIRoad



    本案很有意思,值得进一步研究。我将继续提供有关本案的分析和评论,欢迎大家阅读、参与讨论。

    为什么推行敏捷非要从 CI 开始? by Zhang Charlie


    作者 仝键 发布于 2008年9月18日 上午12时19分



    在 AgileChina讨论组里,每隔一段时间总会有一个重复的问题——我应该从哪开始推行敏捷。答案往往都是“从持续集成开始”。可是实际做起来并不像说起来这么简单。这简单回答的后面是一条艰难的历程。


    推行敏捷应该从哪开始,显然这是一个敏捷 FAQ。但为什么在 AgileChina 讨论组里,正如仝键的发现,答案往往都是“从持续集成开始”呢?




    这是一个有趣的问题,我试着来解答:



    很可能是因为你接触的大概都是像 Jeff Xiong 这样的 TW 员工,或者他们的追随者及其亲朋好友们吧。大家都围绕着 TW 的方法和产品来谈敏捷,自然容易得出这样一个印象了。



    听说 AgileChina 是由几位 TW 员工在业余时间举办的,而“推行敏捷从持续集成开始”也是熊节(Jeff Xiong)所推荐的吧,InfoQ 上好像有相关的文章。



    众所周知,CC 和 Cruise 等是 ThoughtWorks 公司著名的持续集成工具产品。无论是否有组织,TW 及其员工推销自己公司的理念、方法和工具产品,无可厚非,很正当。



    关键一点:我们应该分清什么是市场宣传,什么是科学的结论。很多时候,市场宣传(如广告)合情合理,但不一定科学和客观。而“推行敏捷从持续集成开始”,在我看来更像是一种主观的市场宣传和劝导,而不是客观、科学的结论。



    “推行敏捷从 Practices 开始”或者“推行敏捷从 CI 开始”,可能问题还不大,但如果有人把它们理解成“推行敏捷最好从 CI 开始”或者“推行敏捷一定要从 CI 开始”肯定是错误的。

    推行敏捷从理解敏捷开始 by Zhang Charlie

    那么,推行敏捷应该从哪里开始呢?



    这个问题可能有许多种答案,“推行敏捷从理解敏捷开始”应该是其中一个比较正确和可靠的答案。推行敏捷时,如果连什么是真正的敏捷,实施敏捷到底意味着什么,都没有搞清楚,那么在错误理解敏捷的基础上推行敏捷还有可能成功吗?当然不可能(或者可能性很小)。这显然是每个人理应都明白的废话。



    尽管“推行敏捷应该从理解敏捷开始”是废话,但是网络(包括 InfoQ)上公开出来的许多敏捷实施失败案例,导致失败的根本原因恰恰是因为敏捷的推行者、实施者(尤其管理者)错误理解了敏捷,有的做法甚至明显偏离了敏捷的基本目标和价值观,而他们依然自信满满地认为自己对什么是敏捷相当了解。这就是我们要始终不断地重复强调废话的原因。



    推行敏捷从哪里开始?简单说,中式太极敏捷认为一种可行的、比较合理、符合逻辑的步骤(或阶段)是:



    1、认清真正的敏捷



    通过学习和调研,认清什么是真正的敏捷。如果一些基本初始概念就错了,那么在后续的推行中必然会差之毫厘、谬之千里,希望通过真正的敏捷实施提高开发效率和质量,比传统软件工程做得更好,也就无从谈起了。



    2、预估推行敏捷的收益



    在确认知道什么是真正敏捷的前提下,对自己团队、组织的现状、问题和薄弱环节进行评估,设定改进目标,并预估敏捷能否解决这些问题,带来哪些潜在的改进和收益。如果成功的把握小于 50% 或者现状已经足够好,就不要推行敏捷,何必劳民伤财,得不偿失呢。



    3、采取具体措施推行敏捷



    到了这个时候,才谈得上具体采用敏捷的哪种具体做法,从哪个点、薄弱环节切入进行改进,是敏捷需求,敏捷估算,敏捷计划,敏捷设计,敏捷测试,还是持续集成,或者其它 ... 敏捷 Practices 有几十种之多,CI 仅是其中的一种,而且从软件工程工艺的上下游关系看,CI 也不是应该优先考虑的敏捷实践。



    如果问的是,推行敏捷做法从哪一种做法开始?可靠的答案是:不知道。不同的公司,不同的团队,遇到的实际问题和困难不尽相同,脱离具体环境,我们其实很难给出一个明确的答案,究竟推行敏捷从哪一种或哪几种做法开始,往往取决于对企业现状评估的结果。如果非要张恂给出一个首先项答案,我想一开始应该也不会包括 CI。



    持续集成仅仅是推行敏捷起步的一个可选项,并非必须的。如果你们公司真的是因为软件集成频度不够出现了严重的问题,那么推行持续集成,大幅度提高集成频度,缩短集成周期至几小时以内,才有可能是合理的。



    XP 是敏捷的,但敏捷不是 XP。认为一旦推行敏捷,就必须要做到 XP(或 XP 的某些做法),是一种常见的误解,受到了某些不恰当 marketing 的误导。推行敏捷方法、敏捷过程,其实有很多除 XP 及其措施之外的可选项和可行方案,包括 Scrum、Lean、AgileUP、中式太极敏捷以及各种自制的敏捷方法等等。



    敏捷也不是某种具体的做法(practice),敏捷不是 TDD,不是 PP,也不是持续集成。在缺乏对敏捷和软件工程基本原理正确理解的情况下,盲目地推行某种敏捷甚至极限的具体做法,往往会导致幼稚的失败。



    中西合璧的敏捷 OO 教练


    www.zhangxun.com

    是否可以多级多粒度的持续集成 by 翔东 钱

    嗨,仝键,看了你的文章很受启发,再结合我曾经参与过的项目经验,写了一篇文章,试着探讨解决你的问题的途径。请你指教。
    因为写的比较多,我也不知道怎么在InfoQ里发文,所以放在了一个了一个朋友的博客上面
    blog.tianya.cn/blogger/post_show.asp?idWriter=8...

    允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

    当有人回复此评论时请E-mail通知我

    允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

    当有人回复此评论时请E-mail通知我

    31 讨论

    登陆InfoQ,与你最关心的话题互动。


    找回密码....

    Follow

    关注你最喜爱的话题和作者

    快速浏览网站内你所感兴趣话题的精选内容。

    Like

    内容自由定制

    选择想要阅读的主题和喜爱的作者定制自己的新闻源。

    Notifications

    获取更新

    设置通知机制以获取内容更新对您而言是否重要

    BT