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

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

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

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

这就是企业级软件吗？

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

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

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

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

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

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

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