|
锁定老帖子 主题：持续集成工具的选择
精华帖 (5) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-12-08
daquan198163 写道 持续集成是最佳实践没错，但也得在完善自动化测试之后才能发挥作用，否则就变成持续编译了。
虽说也有那么点儿作用，但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。 你恰恰搞反了 在你说的这种“自动化测试不完善”的情况里，项目经理的诉求是“完善的自动化测试”，持续集成是牵引团队达成这个目标的手段 很多同学没有搞明白一件事 持续集成没有任何用处，如果你不去持续改进的话 持续集成是项目体征可视化的手段。它让你知道项目有多健康（或者多不健康）。用这个信息作为牵引，你不断改进，然后你不断看到成果，成果再次增加你改进的动力，形成正向反馈。 如果仅仅做个持续集成就想让项目变好 你发现自己肝疼，于是你去医院体检，发现自己得了脂肪肝，然后你开始特别关注自己的健康状况，你每天都去医院体检，你对自己病情的发展了如指掌 你的病会因此而减轻吗？ |
| 返回顶楼 | |
|
发表时间：2009-12-09
gigix 写道 daquan198163 写道 持续集成是最佳实践没错，但也得在完善自动化测试之后才能发挥作用，否则就变成持续编译了。
虽说也有那么点儿作用，但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。 你恰恰搞反了 在你说的这种“自动化测试不完善”的情况里，项目经理的诉求是“完善的自动化测试”，持续集成是牵引团队达成这个目标的手段 很多同学没有搞明白一件事 持续集成没有任何用处，如果你不去持续改进的话 持续集成是项目体征可视化的手段。它让你知道项目有多健康（或者多不健康）。用这个信息作为牵引，你不断改进，然后你不断看到成果，成果再次增加你改进的动力，形成正向反馈。 如果仅仅做个持续集成就想让项目变好 你发现自己肝疼，于是你去医院体检，发现自己得了脂肪肝，然后你开始特别关注自己的健康状况，你每天都去医院体检，你对自己病情的发展了如指掌 你的病会因此而减轻吗？  我认为项目可视化是关键词，这其中包括了很多实践，比如说测试、比如说各种报表
|
| 返回顶楼 | |
|
发表时间：2010-01-18
daquan198163 写道 zgsheng 写道 wsgwz_2000 写道 daquan198163 写道 aqingsao 写道 “任何稍微专业一点的团队都能保证代码编译通过吧？” ──未必，即使一个小团队，也会出现check out代码本地编译不过的情况，更别说大型团队和分布式团队了。没有持续集成，代码的集成会是噩梦。 简单，规定提交前先update，这好像是基本常识 这样的团队就是用了CI，也只是天天听到报警 这种现象：check out代码本地编译不过的情况 我们项目，不管大小，不管是我们这边单独开发还是和日方联合开发，也几乎不会出现这种现象 也是靠很简单的“规定提交前先update”和“谁出错谁恢复” 听过这样的说法：持续集成是项目的呼吸（还是心跳？） 也在项目里试用过CC，可始终没感受到这种呼吸（心跳？）的感觉， 因为项目组成员普遍反映体会不到什么好处，所以放弃了这项实践 （我们只用来跑跑测试，也许是方法不对吧） 对于集成，我们更看重的是关联业务间的集成， 接口的正常是必须的，更重要的是对关联数据和逻辑的集成， 因为在以往的项目里这一块出现的问题比较多，所以现在要求在单体测试阶段就提前加入对集成的考量 是否我们公司之前的持续集成实践完全走错了路？ "规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人. "谁出错谁恢复" 这个"谁"是谁?你知道吗? 在已有稳定的底层开发框架,团队开发人员各自开发与其他人都无关联的模块的情况下，你的情况是可行的. 如果从低层开始或者模块互调频繁......数据强耦合,不做持续集成,简直就是噩梦 您做过开发么？ 难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？ "谁出错谁恢复" 这个"谁"只要看一眼svn日志就可以找到。 是啊，'提交前先update'，不可能啊，尤其反感VSS,CC那种独占式的修改，提交时有冲突自行Merge就可以了啊 |
| 返回顶楼 | |
|
发表时间：2010-01-21
不同的工具應該適用于不同的公司環境，開發團隊吧。
外包公司，公司有一個項目共計100+人，開發有60+人（基本都是剛畢業的），測試20+，分開發部測試，測試部測試，還有客戶測試版。每天都有人專人打包，部署，測試，三天或一周提交給客戶測試一次。天天都有狀況，少提交代碼了，打包沒有成功了，部署沒有成功了，集成那個亂呀，真是沒法說。還是人多呀，有人的地方，就有爭端。 像我們這里的情況，持續集成絕對是利大于弊的。 |
| 返回顶楼 | |
|
发表时间：2010-02-26
gigix 写道 daquan198163 写道 持续集成是最佳实践没错，但也得在完善自动化测试之后才能发挥作用，否则就变成持续编译了。
虽说也有那么点儿作用，但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。 你恰恰搞反了 在你说的这种“自动化测试不完善”的情况里，项目经理的诉求是“完善的自动化测试”，持续集成是牵引团队达成这个目标的手段 很多同学没有搞明白一件事 持续集成没有任何用处，如果你不去持续改进的话 持续集成是项目体征可视化的手段。它让你知道项目有多健康（或者多不健康）。用这个信息作为牵引，你不断改进，然后你不断看到成果，成果再次增加你改进的动力，形成正向反馈。 如果仅仅做个持续集成就想让项目变好 你发现自己肝疼，于是你去医院体检，发现自己得了脂肪肝，然后你开始特别关注自己的健康状况，你每天都去医院体检，你对自己病情的发展了如指掌 你的病会因此而减轻吗？ 视角不同，有人只看到了结果，有人在关注过程。但是，大家在实践中往往忽略了过程，而想要一蹴而就得到理想的结果。 如同gigix所述，持续集成推动了持续改进，有了过程才能得到理想的结果。 |
| 返回顶楼 | |
|
发表时间：2010-05-15
最后修改：2010-05-15
持续集成没有任何用处，如果你不去持续改进的话 这不是废话吗，
我想知道做什么东西不需要改进的？而是你通过什么方式来改进，这不就是本帖讨论的目的嘛 貌似zhuangbility的不少啊，废话一堆 |
| 返回顶楼 | |
