持续集成与build的周期

Scott · 发表于 2008-7-3 14:09:47

[转载自网络]
敏捷软件开发中一个重要的实践是"持续集成",而不同敏捷程度的开发团队在实现持续集成的方式上有很大不同,而集成形式的问题有时候会使问题本末倒置,使开发者迷失了"持续集成"本来的意图.

持续集成是持续地维护一个进化中的软件产品.为什么要维护这样一个产品呢?用敏捷开发的一个基本原则来解释就是:一切对与错,只有通过可操作的产品才能最终评判.

所以,持续集成的目的是为了尽可能早的获得有效的反馈.反馈周期越短,反应速度越快,开发过程驾驭变化的能力就越强.

如果用monthly build,反馈信息的规模是以change request/requirement packet来计算的,如果用weekly build,反馈信息以feature来计算;如果用daily build,反馈信息规模以task来计算;如果随时创建,反馈信息的规模则可以以代码行来计算.

试想,如果产品中出现一行不恰当的代码即可引起开发者立即反应,这样的效率一定是一个已经达到非常高的敏捷程度的开发团队才能实现的.

上一篇：因果图方法设计象棋马走日的测试用例
下一篇：软件测试流程(TestFlow)

iamredeye · 发表于 2008-7-3 14:52:16

大家integration的周期一般是多久？

sungubbi · 发表于 2008-7-3 15:25:39

解答一下我的这个问题。:)

http://www.step365.com/bbs/thread-833-1-1.html

lily_014 · 发表于 2008-7-3 17:11:44

看项目的阶段来规划，大规模的编码和集成测试阶段采用daily build。否则报告里面也没有什么改变的东东。

iamredeye · 发表于 2008-7-3 17:36:58

原帖由 sungubbi 于 2008-7-3 15:25 发表
解答一下我的这个问题。:)

http://www.step365.com/bbs/thread-833-1-1.html

你说的产品集成是不是就是 product configuration mgmt? 具体说就是公司针对不同客户维护不同的版本或功能等等？

sungubbi · 发表于 2008-7-4 09:42:55

不是的。

我所指的产品集成，有几种情况：
１）软件产品本身各模块或功能的集成，最后形成该产品可执行的产品包。
２）多个软件产品的集成，此时涉及布署问题。
３）（多个）软件产品＋硬件（如小型机）＋支持软件（如ORACLE）的集成，形成最终可正式使用用的产品，此时涉及布署问题。这种情况可能更多时叫做系统集成吧。

iamredeye · 发表于 2008-7-4 11:29:29

软件产品＋环境（比如编译，运行环境）？

硬件环境会一起集成吗？还是仅用BOM（bill of material）来描述？

Scott · 发表于 2008-7-4 23:13:36

被大家说糊涂了，就我理解说两句吧，我没参加过CMMI认证，所以没法揪这个“产品集成”这个字眼。就我的理解，产品集成，就是通过某种方式集成为产品，这里应该不涉及到部署，但涉及到软硬件集成。

对于纯软件来说，我们完全可以每日构建的集成；如果系统复杂，可以分为多个模块，分别Build，这个例子我举过，比如A,B,C,D，A和B先Build，C和D再Build，最后ABCD合在一起Build，这种Build的策略、环境和各模块之间的接口都属于产品集成。对于软硬件的也是一样，只要把软硬件看成模块就可以了。

timlq · 发表于 2008-7-4 23:27:31

粒度的问题。
取决于项目与产品的集成方式，据项目自身来定义。

iamredeye · 发表于 2008-7-11 14:17:43

刚好这几天在关心持续集成，我感觉很关键还是unit/itegration test cases的有效性，因为看到有些人也在比较频繁的集成，但testing不到位，实际上没办法发现并解决更有风险的问题。

101℃太阳 · 发表于 2014-2-20 16:12:47

很有借鉴意义，先收藏了，谢谢楼主。

深海有鱼j · 发表于 2014-6-10 15:19:47

路过的帮顶

不哭了i · 发表于 2014-6-23 18:45:34

其实，很多情况下都是这样的，习惯就好。

最强ID · 发表于 2014-9-29 12:40:30

没人回帖。。。我来个吧！

记者小脚丫 · 发表于 2015-4-24 13:51:55

向楼主学习

持续集成与build的周期

逛了这许久，何不进去瞧瞧？