在我现在的项目中出现了这么两个问题，大家可以来探讨下这样的两个问题的解决方法，:)
1、从开发环境到正式环境的部署/校验非常麻烦
目前所有的代码都在SVN上，但每次从开发环境到正式环境的部署都非常的麻烦，经常会出现的问题是环境配置的不一致，代码的不一致等。
另外的一个问题就是当从开发环境部署到正式环境后需要人工来进行回归测试，以确定正式环境的效果和开发环境一致，和这个问题的类似问题是当开发环境做出一个大的调整时，也需要人工的对之前所做的功能进行回归测试，这两个过程经常会耗费非常多的时间，而且最重要的是正式环境的再次回归测试可能会涉及到覆盖率不全的问题，这个问题是比较严重的。
2、数据库的频繁移植/校验非常麻烦
目前的项目中需要将原系统的SQLServer库移植到Oracle库，但这两套系统会有一段时间是并行运行的，但结构/数据/存储过程等都以原系统的SQLServer库为准，这也就导致了数据库会经常隔一段时间就要进行移植，由于原系统是一直在开发阶段和运行阶段的，这就是说每次移植时可能都会有数据库结构的改动、数据量的改变、存储过程的改变等，加上原系统那边持续开发时没有明确的数据库变更版本记录，这也就导致了每次都不得不完全进行重新的移植，这是一件极度痛苦的事。
另外一方面的问题就是，当数据库移植完毕后，每次只能人工的去检查移植是否成功，而这个检查的过程也是比较的繁琐和耗时。
对于上面两个问题，我自己想到的解决方法是：
1、建立持续集成机制，编写环境部署脚本和文档，采用这两种方法可保证从开发环境到正式环境的部署是非常简单的；
编写自动验收测试脚本，可以基于Selenium进行编写，这样每次在升级版本的时候就不需要再人工的进行回归测试了，这里面的问题是如何在测试完毕完毕后清除这些测试数据，因为这些测试数据是不能和正式数据共存的。
2、建立数据库升级移植机制，每次升级时做增量的升级，不过这需要建立在对原库建立版本记录，这个方法对于我们的项目而言不太可行；
第二种方案就只能每次进行全面的重新移植了，但这个带来的一个巨大问题就是存储过程的修改工作会带来重复，目前我还没想到什么解决方法；
至于如何校验数据库移植是否成功，我觉得可以建立数据库移植校验的Checkpoint，除了保证数据库结构、数据量等的移植一致外，对于存储过程的校验也许需要根据SQLServer处存储过程的运行结果来建立对于移植到Oracle的存储过程的单元测试，以确保存储过程的一致，不过对于存储过程的单元测试好像还没找到什么好的工具，大家能否推荐下，另外就是和解决第1个问题同样的问题，如何保证测试数据和正式数据的隔离，但又能保证通过测试后在正式的环境下是肯定一致的。
最后还是得运行自动的业务测试，确保数据库的升级移植成功完成。
对于测试数据和正式数据的隔离，我目前知道的解决方法是这么两种：
1、在移植到正式库前先将目前的运行库复制一份到一个新的用户下，然后将库移植到此用户下，进行测试，当测试成功后再将此库切换为正式库，这种方法的问题呢，是运行库得停止一段时间，否则会造成一定的问题。
2、另外一种做法就是采用内存库的方法，但这个问题是得把运行库的数据也放进去。
保证测试数据和运行数据的隔离对于不断的升级运行系统是很重要的。
测试驱动和持续集成是敏捷最佳实践指导中的很关键的两个要素，而在这样的场景中就很明显的体现出了它的好处，不知道大家对于以上两个问题是否有更好的建议呢？