|
锁定老帖子 主题：较大项目组的集成周期多少才合理?
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-08
我同意o6z的观点：唯一的限制是你的机器是否能跑得动，以及你是否愿意做。一个子项目总有自己的构建脚本吧？再写个脚本把这些子项目整合起来跑冒烟测试，这又会多难呢？
|
| 返回顶楼 | |
|
发表时间：2004-09-08
agilecat 写道 ozzzzzz 写道 agilecat
我晕!!!
nt的开发队伍是几百个coder,几千个测试员.他们都可以做到你为什么做不到.根本就不是什么沟通问题,而就单纯是一个态度的问题.每日集成并不能消除什么bug,他只是告诉你那个bug还存在.任何一个软件也不可能没有bug. 同时纠正一个你的错误认识.发布一个版本和构造一个版本并不是一个概念,发布时需要满足很多的条件,上面你引用的那些就是xp发布一个版本的时候应该满足的最基本条件,然后还要加上稳定性和性能等等的约束满足需求,文档提供的充分并且和版本同步等等其他条件.但是构造一个版本则简单的多,只要你的代码放在一起就可以算一个版本,即使你并没有对他们作任何的编译也可以算一个版本. 那么对于上百人,多个子项目组的项目大概应该多大频率成功编译,测试也都通过的一个版本呢? 建议大家调整一下论题方向,我门讨论的是多个子项目组之间松耦合的集成问题. 不要问我为什么盖茨那么有钱,而我则那么穷. Google Gump. 如果你项目规划的好，组建分割的比较清晰，这种松耦合继承还是比较容易的。 Maven也可以做到。 至于多大频率，一般最好每天晚上做一次。这样做的目的不是要看到编译有没有成功，而是要看到在现在有的单元测试基础上的集成有没有失败，有没有人在今天的工作中提交了破坏“软件需求”的代码。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
那么编译不成功，单元测试失败该如何处理呢?
因为我想知道编译成功,单元测试成功的周期,而不是相反 |
| 返回顶楼 | |
|
发表时间：2004-09-08
谁提交的代码失败，就发邮件灌爆他的信箱，直到他把问题解决掉为止。所以集成的服务器性能得好，最好是能在10分钟之内完成集成和测试。
|
| 返回顶楼 | |
|
发表时间：2004-09-08
agilecat 写道 那么编译不成功，单元测试失败该如何处理呢?
因为我想知道编译成功,单元测试成功的周期,而不是相反 这个周期取决于你公司的制度和团队的成员水平。这个周期一般就是你们公司 需要创建新Build的周期。当然便以成功，不代表是一个合格的Build。 Gigix说的可以帮助你，如果你项更快的通知你的成员，他提交的代码 除了问题。可以使用IM工具。 |
| 返回顶楼 | |
|
发表时间：2004-09-12
说实话，对于这样的项目，我是不赞成全项目整体的进行日集成，哪样成本太高，而且，说实话，我也不太相信谁可以做好。
介意楼主还是看看ClearCase的UCM的概念吧！（虽然的确是贵了点，不过对于这么大的一个项目，一个Clearcase算得上什么），采用小组集成与小组间的集成结合是相当不错，也是自有它的道理的。 小组进行细分，同时进行小组内日集成，而小组间根据基线采用阶段集成（比如周或者数日）。 |
| 返回顶楼 | |
|
发表时间：2004-09-12
凤舞凰扬
你真的应该去算算这样一个项目使用CC的成本到底是多少,反正我是没有看到过国内有人在如此规模的项目上使用CC. 而且我不知道你怎么会认为全项目日集成为是高成本的做法.MSF的一条最被人接受的经验就是日集成可以大大降低成本,而不是提高.实际上我们大家谁都明白,已经通过了个体的单元测试,而在集成中产生的BUG往往是最难于解决的,也是往往给项目进度带来最大影响的bug.这样的问题最应该在最早期的时候发现. |
| 返回顶楼 | |
|
发表时间：2004-09-13
to凤舞凰扬
我们已经购买了CC，对于我们超大项目组，购买cc还是付的起的，另外大公司买开发工具都会有很大折扣的，不能用市价去计算。 你所说的不太相信谁能作到全项目整体的进行日集成，我认为，成熟的组织是可以作到的，比如胖子提到的微软，但国内大公司的管理开发成熟度较低，如果不能从全面提升成熟度，单纯地全项目日集成是有困难的 |
| 返回顶楼 | |
|
发表时间：2004-09-13
agilecat
看来你们真的敢于投资上百万来建立你的SCM系统了.不知道你们使用这样的系统有多久了,如果只是才开始,基本上来说CC带来的麻烦要比给你们的好处多的多.要注意这个问题. 其实每日建造需要的基础并不多,只是要有每日checkin和checkout的制度作保证,然后就是一台强健的编译服务器了,这样的条件基本上所有的组织都具备.每日建造可以说是走向成熟组织的一个最有效方法,而不是要以组织成熟为基础的一个过程. |
| 返回顶楼 | |
|
发表时间：2004-09-13
cc带来的问题确实不少，关键是cc需要专业配置管理人员配合才搞的定，不象vss随别用用就玩溜了，我们的问题是专业配置管理人员太少(2人/100多开发人员)，并且好象还不很专业,没办法，其实我并不想用cc,老觉得大材小用，感觉跟过度设计似的。
|
| 返回顶楼 | |
