项目进行二次开发，源码更新办法?

Question

    由于业务发展原因，之前开发的系统已经满足不了现在的业务需求了，所以后续对系统的二次开发会比较频繁；
但是这里就会涉及到一个问题：系统是用java写的，所以每次上线之前都会先把文件编译后，然后在生产线把相应的class文件会先备份后，然后覆盖。我想问的是，目前这个上线操作在市场上有没有比较成熟一点的更新方法，或者有其他的辅助工具？背景描述：
由于现在我们有几个人专门对那个系统进行二次开发，也有比较规范的通过那个CVS来进行版本控制。可这样做的话，需求上线之后，系统有时候还会出现问题。因为每个人负责的需求可能不一样，比如A需求已经处理完毕，B需求还在测试阶段，但是A需求急着要上线，这时就会将B需求的相关源码也更新上去，但是B需求就会更新不完全，这样就造成生产源码管理不规范，系统出现问题的频率会比较高！目前的想法就是：想在上线这个步骤上，做一个紧急的回退机制。万一系统出现问题之后，但是问题暂时找不出来的情况下，可以尽快回退到之前的版本，而不影响业务的进行！
所以请有经验的相关人士，提供一下你们的上线步骤，或者有什么比较好的更新工具或办法？

Answer 1

我们的更新方法跟你的一样，也是更新更改的class文件。
但是每次把文件给系统运维部门更新，他们在更新的时候，如果是覆盖文件的话，会备份一份。
出了问题就把备份的恢复过来。

Answer 2

cvs这工具没怎么用，处理版本并发似乎不强。我们公司用IBM ClearCase 对于不同的版本会建不同的开发流
比如Version 1.2.1和1.3.0两个版本是同时开发的，每个版本都是继承至1.2.0。版本发布生产线后，ClearCase将上线版本归并到继承流
int
  -  fint 1.2.0
       - dev1.2.0
  -  fint 1.2.1
       - dev1.2.1
  -  fint 1.3.0
       - dev1.3.0
其中int流是生产的，fint流是上staging(测试环境，也叫sandbox)，dev是开发用的。每次开发移交staging环境就会把修改的文件归并到fint流。测试完后将fint版本流归并到int流。
如上：fint1.3.0上线后会将fint1.3.0和int流进行比对归并（自动），如有冲突的地方由开发人员识别手工归并。至于项目发布。我们采取：
1.发布应用程序版本，发布ear包
2.发布数据库版本，发布SQL脚本
3.修改配置文件，由部署人员根据部署说明项手工添加。
4.特殊部署（对于非正规系统的部署由部署人员手工执行）
以上1的应用包由编译平台脚本通过ant自动编译打包，并交付给部署人员，部署人员通过脚本命令进行部署
2通过脚本自动执行脚本内容
3.手工执行       

Answer 3

回滚：
系统未能正常上线需进行回滚，并通知开发部门领导，开发人员，运营人员，版本经理，部署部门领导，测试人员，测试领导1.常规系统版本回滚，取上个版本的ear包，重启服务即可
2.配置文件的回滚，按照部署说明的内容进行回退，或者按照回滚章节的步骤进行回滚
3.数据库脚本回滚，数据库脚本上线，涉及到dml的脚本需要评估数据量，执行时间，并提供回滚脚本，验证方案。按照提供的回滚脚本进行回滚。
4.环境的回滚，按照部署说明提供的方案进行回滚。