Re: 提交CVS+手工填写单子=后期维护？

google了一下，居然发现ozzzzzz在CSDN上也针对类似问题有一个长篇的发言。而且还是2003年的时候，没想到我们现在也还在重复相同的错误。 问题： [quote] 两年前着手的项目，用了8个月，完成1。0版本，在客户那儿使用，初验结束了，后来根据客户的要求，加了许多新的功能，版本升到了5。0，但是，用我们产品的客户有4家，功能在增加，版本在升级，分支越来越多。 用CVS，VSS来做版本控制，可是，还是一团糟。有了历史记录，可是找一个文件很麻烦，得查一堆的文档，烦死了。 想从配置库中找到当前的最新项目情况，看不出来。 分支，合并的太多了，看管理的历史文档，一堆，头大了。 想查一下，当前的产品5。0版本下面有那些模块组成，那些在4。0的基础上做了修改，那些是新增加的模块，太难了。 产品开发容易，维护难啊，管理明白了更难！ 我该怎么办啊？ [/quote] 这里是ozzzzzz回复中最长的一篇，也是个人以为更有价值的： [quote]在开发中，我们一般情况下是首先建立一个单一的版本(我是没有看到过多版本一起的开发的新产品，即使有也是先建立一个基线产品，然后在对其做增减）。而在建立这个版本中会有多次的集成。当然你可能运气超好，或者水平超高，就安排一次集成，就一次ok。否则就必须多次集成，不这样你的集成测试所发现的bug也不可能被修改啊。而集成bug是系统内的兼容bug，最为让人头疼，寻找麻烦，修改也麻烦。所以XP才搞一个持续集成，MSF来一个每日建造，不是说他们水平高，而是他们认为自己水平不高。当然也许你们水平高，能从一堆代码中找到bug，可是即使如此你们一样要化时间。而减小每一次集成之间的时间，就可以减少每一次修改和新增的代码数量，也就更容易对bug定位。就是因为水平低，才需要更大密度的集成，而不是隔两三天把一批bug修改完毕再去集成。我的经验每修改3个bug，就会出现一下新bug，而每多100行新代码就会多付出1个小时的寻找bug的时间。所以即使是winNT这样的千万行代码的项目也坚持每日建造，不是别的，而是被层出不穷的bug搞怕了。当然世界上有linus这样的英雄，他说好程序员就不会写有bug的代码，所以他们的linux内核就一直不加入debug功能。你要是觉得你至少不比他差，你也可以随便搞。 而每一次建造会得到一般版本，这样的版本我们叫build，它只是通过了白盒测试的版本。而你所做的内部黑盒测试就是，针对这些build的。当你的这些黑盒测试达到一定水平的时候，你就要沿着版本树向上测试，当到达最后一个完全通过的版本时，你就把那个版本确定为release。而我们说的阿拉发版本和贝塔版本，你就可以认为贝塔是这个release，也可以认为阿拉发版是这个release，而通过一定的客户测试后得到的修改版是贝塔，这写你们可以自己选择。而最后当这个发展后的release，你判断它已经符合市场的要求，达到成品标准的时候，你就可以认定它为一个standard，这就是一个真正的产品版。你从我上面的表达可以看出，standard肯定是一个release，而release不一定是standard。每一个release都是一个build，而build不一定是一个release。那么standard也是一个build，而build不一定是一个standard。于是有极端的人要求，每一个build，都必须达到standard的外在标准，比如如果你会以cd发布你的软件，那么你得到的build就应该是cd，如果是dvd，你就应该拿到dvd的build。需要用户手册，那么你的build也必须有那个手册，总之每一个build除了bug和功能的差异，和真正的产品都完全一样。当然我觉得这有些过分，它也告诉你build，不是那么简单的把代码放到一块就可以了，你必须为其准备集成测试，还要把他们完全编译。 这是简单的单版本情况，而实际情况往往是多版本同时开发。比如当你有了standard1·0之后，你要维护它，修补bug，于是会不断的推出1·1－1·2之类的版本。而同时你还在开发新的更多功能的2·0版本。这些版本间有共有的代码，注意是代码而不是模块，特别是那个小火柴，一定要理解这些共有是建立在代码基础上的。比如你修改了一行代码，那么你的版本升级了，可是你并没有模块级的改变。在多个版本共同开发的时候，你会发现有不同的几个standard和release以及build，这个时候就要建立他们不同的分支。而由于有cvs等版本控制软件的支持，我们可以很容易的得到当前的最新版本和以前的任一版本，这是因为你的每一次集成都会被记录到你的资料库中。这些资料要包括你测试的版本，代码的版本，建造的时间，产生bug的记录。这些都是可以用工具自动执行的，如果达不到自动，就去查查手册。 而不同的体系版本间会有兼容问题，这也要看你的产品策略。我们以简单情况为代表，这个时候你的新开发的代码如果不使用在1·0的系统下，就只要去考虑对于其在2·0体系下的测试。而你要为修改的1·0的bug，则你要看在2·0是不是也同样有这个bug，如果有就说明这是你在原始代码中的bug，你需要回归测试到0·0，寻找到底是那一点代码产生了这个bug。而如果只是1·0体系下的bug，则当然只要回归测试到1·0。 其实说了半天，没有什么复杂，关键是要坚持做到每一次少提交一点代码。而那些记录其实都是可以由程序自动完成的。[/quote] 考虑： 1、如果采用持续集成，就意味着需要为现有的代码添加大量的测试代码，这个工作量委实不小。 2、项目存在纵向（升级、添加新的功能）和横向（不同的客户要求）的版本差别，那其实每个版本之间的测试代码也是存在差异的。如果在某个版本的测试中发现了问题，就需要再在其他版本的测试代码中添加类似的单元测试以求正是否存在类似的bug。 3、公司现在考虑将来把新开发的功能从分支上merge到主干上，这个其实也是冒着巨大的风险的，因为没有持续集成。