较大项目组的集成周期多少才合理?

     clearcase不要上百万吧？我以前澳门的公司就是用这个啊。再说，对于一个上百人规模的项目，这个也不算什么的。
   不过o6z兄说的对，开始用clearcase的时候会很不习惯，并且会出现很多问题，我们当时也是半年后才整个团队熟悉。
   另外，对于上百人的团队，不能采用基本方式的配置管理，而必须使用基于UCM的方式，而采用这个方式，对于小组之间的代码就不是check in /check out那么简单了，必须deliver/rebase stream了，并且，每一次都必须建立base line，才能让另一个小组看到，相当的繁琐，而且，它也是区别于其他配置管理器（或者说强于其他CM）的一个地方。所以日构建，基本是相当麻烦。
   而且，说实话，我不清楚中国是否有企业做到了，我一个朋友再金碟做SEPG，金碟也做不到每个项目如此（小的自然可以）。所以我认为，降解集成粒度是比较合适的方法。

大家说了这么多,可能都没注意到楼主的关键问题其实在这里:

其实Martin Fowler在《Refactoring》里已经告诉我们答案了，有一节好像是讲重构的难题，其中一个就是接口修改。这时我们需要同时维护新老两套接口，并且将老接口标为过期Deprecated，这样调用者编译的时候就会注意到，待调用者将调用代码全部改为调用新接口，就可以安全的删除老接口了。另外在过渡期间，千万不要在新老接口的实现之间copy-paste，要尽量用新接口实现调用老接口的方式，原因就不必讲了吧

其实我们一直都是这么做的，虽然麻烦一点，但这也是尊重他人的表现，是吧？

凤舞凰扬
使用cc的成本绝对不是购买成本(况且cc的价格也是最贵的),其对应的培训和服务价格也是很贵的,而维护和初期以至于后期的维护费用都是高的可怕.我说上百万其实还是尽量上说了.
作为一个100人开发的队伍至少应该配备8名左右的cc管理人员(也就是2个小组最少要有1个专门的scm管理员,而关键部位则需要专门的人),这笔开支也不小.其实在我看来如果没有使用rational的全套工具,单纯的使用cc价值并不大,而如果你的文档维护量也不多,这个价值就缩水的更加厉害.
而说实际的cc对持续集成的支持并不好,当然可能在这个方面我是有些冤枉cc,因为似乎rational的人说过cc可以非常敏捷易用的.而使用UCM基本上在多数情况下除非你的组织相当的严格按照过程形式(也就是按照cmm那套东西作),否则成本的支出就太严重.
而对于这些需要很多人同时参与的项目我大多数情况下都表示怀疑,nt的核心小组程序员从来都是在16人以下,为什么会你却需要这样一个巨型的组织.或许你们也是划分为不同的程序的部分(不是模块级别的部分,而是程序级别的不同),这样才能有点道理.不过如果需要100个程序员的话,你的配备的测试人员和维护等服务人员又要有多少,这个问题我是不敢想.
总之除非有极其特殊的理由,组织一个40以上的团队(包括了所有的服务人员的团队)基本上都是没有必要的.

高频集成是比较通用的叫法

日集成：Nt3.0包含560万行C代码,4万个源文件，构造一个集成版本是19个小时，但还是日构造，每天checkin是15-100次，MS认为没有日构造不可想象，必定失败

IBm OS/400 是一周一次全系统完全构造，共2000万行，1.4万个源文件(c/C++）

Coplion的《组织机构模式》可以看到AT&T的基本所有产品都是日构造的。

     这个非常赞成，人越多，沟通成本就会越高，而一个项目开发中，团队的沟通成本是相当可怕的一个因素，RUP、CMM就喜欢开会，因为它们需要始终保持工件的传递和交流的畅通。我不清楚XP或者其他敏捷过程的方式是怎么样，但是相信那么大规模的队伍，沟通成本是相当棘手的问题。
    嘿嘿，说到最后，我一句话，认为不会存在这样的项目，要么是楼主故意考考我们，提提疑问，要么就是楼主没有了解这个项目（相信是个项目组合，而不是纯粹的一个软件项目，这样的例子比如深圳盐田港、澳门民政总署的项目组合一样）

to 凤舞凰扬:
俺不知道楼主是否和我一个公司的，但是我们就是这样的，100多人的j2ee项目，十多个team，开发沟通起来有困难，但不是特别麻烦，很多的时候就是管理上的力度了，而且这只是web端的，client以及其他的组加起来人还要多好几倍

至于集成，我们也做到日构建，而且随时可以构建，并没有什么麻烦的，team之间的协调很多确实要通过mail,即时通讯，网络会议，以及本地会议来沟通，管理以及规划是非常重要

人数是和项目大小有关系的，team可以切分，但是一个项目上百人是不值得奇怪的

记得好像在哪里看到微软的office项目组曾经花费精力，实现了整个office程序在本地编译，编译一次需要的时间是13分钟；该例子是为了说明依赖关系良好的软件编译效率可以超过增量编译的效果。

我觉得实际的产品集成是最好的沟通方式，一堆break build的信息比一大堆PM开会有用多了。
大家多对一的盯着build manager发布的集成和测试结果就好了，谁的问题谁去改，大家都分不清的问题，扯皮的问题架构师去改。如果本来就要要每周开会沟通，那就因该每周都要build去代替那种无聊的周会,这要看上面需要多细的管理粒度了。

CC是很贵，但也不用每个人都买一个license啊，CC是浮动license的，缺省30分钟踢一次人，可以自己写个工具改成5分钟踢一次好了，提高license的利用率，按10％来买估计就足够了。

CC管理员中的系统管理员技能要求较高，一个公司有两个就可以了，项目的配置管理员最好每个项目/开发小组一个，新员工都可以，主要要细心。