|
锁定老帖子 主题：持续集成工具的选择
精华帖 (5) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-10-14
cristal 写道 非常赞同！我们正在尝试这个proof build，但是好像现在缺少IDE支持，显得还不是很方便，不知道是不是这样？以后你们会有IDE的集成吧？ 感谢您选择我们的产品。对于proof build，我们选择基于agent的方式实现，好处是可以不依赖特定的IDE。同基于IDE plugin实现的方式相比，方便性是有所不如。不过我们在以后的版本中也会陆续增加对主流IDE的支持。 |
| 返回顶楼 | |
|
发表时间：2009-10-14
cristal 写道 看了很多回帖讨论有关持续集成是否必要，我有点无语，持续集成作为best practice已经是毋庸置疑
不懂才问的啊 
很多人描述了持续集成多么多么好，可我却体会不到这个best practice到底"好"在哪 可能是没有没有体验过之前的"不好" 再有个上下文环境的描述，俺就好明白多了 cristal 写道 也不会被该死的经理追在屁股后面骂：XXX，快点回公司，你还有N多bug没有fix！
这个就是没有上下文 
zgsheng 写道 如果从低层开始或者模块互调频繁......数据强耦合,不做持续集成,简直就是噩梦
这个算是有一点上下文，可俺们项目不做持续集成也没做过这个噩梦呀
|
| 返回顶楼 | |
|
发表时间：2009-10-14
zgsheng 写道 daquan198163 写道 您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？ "谁出错谁恢复" 这个"谁"只要看一眼svn日志就可以找到。 抱歉,可能是两种情况，一是大家说岔了，说的不是一回事.再有一种可能就是您还在长身体，理解不了大人说的话.回家多吃点排骨牛肉啥的，长好身体再来吧. 如果是第一种情况，那就请你解释一下你说的是哪一回事儿吧： 引用 "规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人.
你相信的机器如何提交前先update？ 也别拿提交proof build说事儿，这个工作也得靠人，按照你的观点，这种事务性操作也应该交给机器来做的。 至于第二种情况，你确信其他人都能理解你这个所谓大人说的话？ |
| 返回顶楼 | |
|
发表时间：2009-10-14
对于编译不通过，跑回归测试，跑冒烟测试，代码质量检查
这些日构建就够了 甚至一个ant task就够了（俺们项目小，不用要多台机器编译个一天一夜的  ）
对于联调，模块集成，业务集成 首先的疑问是，这里的"集成"是持续集成的集成吗？ 而且，用俺之前提过的俺们的解决方法也就够了 搭个测试环境？俺们有脚本 老板客户要感受项目的健康状况？俺们老板客户只对进度表感兴趣 成就感？感觉还是小里程碑更有成就感，老是持续着，敏感度会不会变低呀 项目健康度的更快反馈？俺还没有所谓的"健康度"这种体会
要是有个现场客户？ 为了他老人家能持续地及时地感受到项目"健康度"，能持续地及时地感受到项目的"呼吸"与"心跳".... 那俺暂时同意持续集成。总不能扔个eclipse给他，或者让他来跑ant task
可因为持续集成是"best practice" 俺不做的话，心中彷徨不安的很 |
| 返回顶楼 | |
|
发表时间：2009-10-14
最后修改：2009-10-14
gigix 写道 andyyehoo 写道 continuum为啥不提呢？上家公司用continuum+maven，基本上实现了所有需要的功能了，效果也不错，配置稍微复杂一点而已。CruiseControl就算了，3年前就那个样子，现在还是这个样子，UI太丑，实在下不了口
嗯，请访问你的cruisecontrol的 /dashboard 一直用cruisecontrol,只注重功能实用,谁也不会整天叮着持续集成看,能够邮件通知构建结果就行了,不管美丑，所以还是比较喜欢看/cruisecontrol视图。 /dashboard就界面好看点，根本没有多少功能提升，瞎整。 |
| 返回顶楼 | |
|
发表时间：2009-10-14
daquan198163 写道 zgsheng 写道 daquan198163 写道 您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？ "谁出错谁恢复" 这个"谁"只要看一眼svn日志就可以找到。 抱歉,可能是两种情况，一是大家说岔了，说的不是一回事.再有一种可能就是您还在长身体，理解不了大人说的话.回家多吃点排骨牛肉啥的，长好身体再来吧. 如果是第一种情况，那就请你解释一下你说的是哪一回事儿吧： 引用 "规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人.
你相信的机器如何提交前先update？ 也别拿提交proof build说事儿，这个工作也得靠人，按照你的观点，这种事务性操作也应该交给机器来做的。 至于第二种情况，你确信其他人都能理解你这个所谓大人说的话？ 别吵了 呵呵 不过我也没理解 不过别鄙视我的智商啊 第二种情况真的看不明白 |
| 返回顶楼 | |
|
发表时间：2009-10-14
CI不是绝对的best practise，要和团队规模、项目周期相匹配，2-3个人几个月搞定的小项目谈什么CI，一个svn加基本的协作开发制度即可，即便10人左右协作开发的项目，上述协作方式 + Ant扩展也够了，若是不管项目实际，上来就扣上CI大法，纯粹是技术强迫症。
|
| 返回顶楼 | |
|
发表时间：2009-10-14
最后修改：2009-10-14
fight_bird 写道 CI不是绝对的best practise，要和团队规模、项目周期相匹配，2-3个人几个月搞定的小项目谈什么CI，一个svn加基本的协作开发制度即可，即便10人左右协作开发的项目，上述协作方式 + Ant扩展也够了，若是不管项目实际，上来就扣上CI大法，纯粹是技术强迫症。
你用的什么协作开发制度可以保证你提交的代码不破坏现有测试？这个我很感兴趣。 |
| 返回顶楼 | |
|
发表时间：2009-10-15
尝试了一下CC和Teamcity,最后选择了teamcity,应用于C++开发
|
| 返回顶楼 | |
|
发表时间：2009-10-16
不知道大家真正的项目有没有把CI用好，看大家的评论好像自己的项目用的很好。
CI这个东东是要用，但是也应该添加一些惩罚措施，比如谁的COde编译不通过允许修改一次，第二次不过就要罚钱了。要是没有惩罚措施，CI这个东东就完全取决于个人意愿了。 有些程序员可能会想：编译不通过就不通过，反正又不是发布阶段。 要是碰到了外包项目，CI的价值就更加体现不出来了，代码都写不完了，谁还去管CI呢？ 所以CI是不是best practise 这个还真的要看场景。 |
| 返回顶楼 | |
