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

项目现在到了后期debug阶段，为了保持发布包的稳定可用，公司先后采用了以下手段：

1、开发人员在向CVS提交代码时描述修改内容和填写的单子号
2、手工填写一份单子，填写bug号，bug内容，修改的class全限定名称，对其他模块的影响；
   提交给某个人去对比CVS和单子上描述的内容。
3，在部署到指定服务器之后，由小组长测试通过，然后再部署到另外一台服务器上由测试组测试。

刚刚又发布了更加复杂的单子填写项目

这就是企业级软件吗？

有没有更好的维护方式？
难道非得回到半自动时代才能限制开发者的随意提交？
是否有更好的解决方式？

评论

10 楼 feygo 2007-03-21  

在测试不能达到自动化的时候，尤其是界面测试，lz的方式麻烦但是有用

9 楼 ozzzzzz 2007-03-15  

我在2000年就得出一个结论——所有问题都是人的问题，而且所有问题的入手的点都可以是SCM。
实际上我对于CMM的从欣赏走向不认同，其实也就是从SCM开始的。最开始是CMM让我知道了有一个SCM，很不幸当去切实的去了解CMM和使用CMM的公司的时候却发现他们的SCM是那么不能让我满意。而对于XP的喜好也是来自我对持续集成这个概念的赞赏，虽然在现实中我不使用XP，但是可以说XP在持续集成方面给了我方法论层次上最大的支持。
进一步说从SCM的角度来说RAILS是一个巨大的进步——在持续的程序结构上给SCM提供了重大的便利，但是我并不认为RAILS做的就足够了。简单的说一个真正高效的开发工具，应该提供从需求到测试的所有开发核心工作流及其产品的SCM支撑。只有这样才能从根本上解决后期维护的成本考量，才能做到持续而平滑的成本输出曲线——这个曲线是XP方法的基本理论出发点。

8 楼 adamzhao 2007-03-15  

google了一下，居然发现ozzzzzz在CSDN上也针对类似问题有一个长篇的发言。而且还是2003年的时候，没想到我们现在也还在重复相同的错误。

问题：

引用

两年前着手的项目，用了8个月，完成1。0版本，在客户那儿使用，初验结束了，后来根据客户的要求，加了许多新的功能，版本升到了5。0，但是，用我们产品的客户有4家，功能在增加，版本在升级，分支越来越多。  
  用CVS，VSS来做版本控制，可是，还是一团糟。有了历史记录，可是找一个文件很麻烦，得查一堆的文档，烦死了。  
  想从配置库中找到当前的最新项目情况，看不出来。  
  分支，合并的太多了，看管理的历史文档，一堆，头大了。  
  想查一下，当前的产品5。0版本下面有那些模块组成，那些在4。0的基础上做了修改，那些是新增加的模块，太难了。  
  产品开发容易，维护难啊，管理明白了更难！  
  我该怎么办啊？  

这里是ozzzzzz回复中最长的一篇，也是个人以为更有价值的：

引用

在开发中，我们一般情况下是首先建立一个单一的版本(我是没有看到过多版本一起的开发的新产品，即使有也是先建立一个基线产品，然后在对其做增减）。而在建立这个版本中会有多次的集成。当然你可能运气超好，或者水平超高，就安排一次集成，就一次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。  
  其实说了半天，没有什么复杂，关键是要坚持做到每一次少提交一点代码。而那些记录其实都是可以由程序自动完成的。

考虑：
1、如果采用持续集成，就意味着需要为现有的代码添加大量的测试代码，这个工作量委实不小。
2、项目存在纵向（升级、添加新的功能）和横向（不同的客户要求）的版本差别，那其实每个版本之间的测试代码也是存在差异的。如果在某个版本的测试中发现了问题，就需要再在其他版本的测试代码中添加类似的单元测试以求正是否存在类似的bug。

3、公司现在考虑将来把新开发的功能从分支上merge到主干上，这个其实也是冒着巨大的风险的，因为没有持续集成，全凭测试组MM鼠标点。如果出了问题，领导就会说我们不敬业。

7 楼 ozzzzzz 2007-03-14  

这个是企业级别的scm混乱综合症。xp有个说法叫持续集成Continuous Integration，你可以参考一下。
经常有人说xp没有文档，起因就是在这里。每次集成，你们的集成服务器不能提供一个完成的报告，这样的企业应该补课了。这些东西都应该是非人工自动化的完成的。

6 楼 basicbest 2007-03-14  

dada 写道

adamzhao 写道

美国总公司的项目，现在有了一个超级客户，公司全力维护。
如果多出现几个客户，不知道又该怎么维护？

到那个时候既要考虑主版本，又要考虑各个客户的个性化需求。
按照这种模式的话，想想就觉得头大。。。

分版本部署其实是一件很幸福的事情。
我这里某客户高层觉得数据太过分散，搞起数据大集中，集中到后面直接把项目都集中起来。
最搞笑的是it部和行政部门互相扯皮，it对行政完全没有约束力，总公司对分公司的约束力也不够，一个版本里面要满足所有分公司的需求，从权限到业务林林总总都有个性化定制的需要。

我没什么想法，只是想说。。。。
可怜的孩子！

5 楼 dada 2007-03-14  

adamzhao 写道

美国总公司的项目，现在有了一个超级客户，公司全力维护。
如果多出现几个客户，不知道又该怎么维护？

到那个时候既要考虑主版本，又要考虑各个客户的个性化需求。
按照这种模式的话，想想就觉得头大。。。

分版本部署其实是一件很幸福的事情。
我这里某客户高层觉得数据太过分散，搞起数据大集中，集中到后面直接把项目都集中起来。
最搞笑的是it部和行政部门互相扯皮，it对行政完全没有约束力，总公司对分公司的约束力也不够，一个版本里面要满足所有分公司的需求，从权限到业务林林总总都有个性化定制的需要。

4 楼 adamzhao 2007-03-14  

抛出异常的爱 写道

又是对日项目么?
如果不是tdd开发这的确是个好办法....

美国总公司的项目，现在有了一个超级客户，公司全力维护。
如果多出现几个客户，不知道又该怎么维护？

到那个时候既要考虑主版本，又要考虑各个客户的个性化需求。
按照这种模式的话，想想就觉得头大。。。

3 楼 dada 2007-03-14  

下面正好有一个测试自动化的帖子...

2 楼 抛出异常的爱 2007-03-14  

adamzhao 写道

项目现在到了后期debug阶段，为了保持发布包的稳定可用，公司先后采用了以下手段：

1、开发人员在向CVS提交代码时描述修改内容和填写的单子号
2、手工填写一份单子，填写bug号，bug内容，修改的class全限定名称，对其他模块的影响；
   提交给某个人去对比CVS和单子上描述的内容。
3，在部署到指定服务器之后，由小组长测试通过，然后再部署到另外一台服务器上由测试组测试。

刚刚又发布了更加复杂的单子填写项目

这就是企业级软件吗？

有没有更好的维护方式？ 难道非得回到半自动时代才能限制开发者的随意提交？
是否有更好的解决方式？

又是对日项目么?
如果不是tdd开发这的确是个好办法....

1 楼 LucasLee 2007-03-14  

我在曾经的一个团队里，也用这种方式，是很麻烦的，也许会有用？