在我現在的項目中出現了這么兩個問題，大家可以來探討下這樣的兩個問題的解決方法，:)
1、從開發環境到正式環境的部署/校驗非常麻煩
目前所有的代碼都在SVN上，但每次從開發環境到正式環境的部署都非常的麻煩，經常會出現的問題是環境配置的不一致，代碼的不一致等。
另外的一個問題就是當從開發環境部署到正式環境后需要人工來進行回歸測試，以確定正式環境的效果和開發環境一致，和這個問題的類似問題是當開發環境做出一個大的調整時，也需要人工的對之前所做的功能進行回歸測試，這兩個過程經常會耗費非常多的時間，而且最重要的是正式環境的再次回歸測試可能會涉及到覆蓋率不全的問題，這個問題是比較嚴重的。
2、數據庫的頻繁移植/校驗非常麻煩
目前的項目中需要將原系統的SQLServer庫移植到Oracle庫，但這兩套系統會有一段時間是并行運行的，但結構/數據/存儲過程等都以原系統的SQLServer庫為準，這也就導致了數據庫會經常隔一段時間就要進行移植，由于原系統是一直在開發階段和運行階段的，這就是說每次移植時可能都會有數據庫結構的改動、數據量的改變、存儲過程的改變等，加上原系統那邊持續開發時沒有明確的數據庫變更版本記錄，這也就導致了每次都不得不完全進行重新的移植，這是一件極度痛苦的事。
另外一方面的問題就是，當數據庫移植完畢后，每次只能人工的去檢查移植是否成功，而這個檢查的過程也是比較的繁瑣和耗時。
對于上面兩個問題，我自己想到的解決方法是：
1、建立持續集成機制，編寫環境部署腳本和文檔，采用這兩種方法可保證從開發環境到正式環境的部署是非常簡單的；
編寫自動驗收測試腳本，可以基于Selenium進行編寫，這樣每次在升級版本的時候就不需要再人工的進行回歸測試了，這里面的問題是如何在測試完畢完畢后清除這些測試數據，因為這些測試數據是不能和正式數據共存的。
2、建立數據庫升級移植機制，每次升級時做增量的升級，不過這需要建立在對原庫建立版本記錄，這個方法對于我們的項目而言不太可行；
第二種方案就只能每次進行全面的重新移植了，但這個帶來的一個巨大問題就是存儲過程的修改工作會帶來重復，目前我還沒想到什么解決方法；
至于如何校驗數據庫移植是否成功，我覺得可以建立數據庫移植校驗的Checkpoint，除了保證數據庫結構、數據量等的移植一致外，對于存儲過程的校驗也許需要根據SQLServer處存儲過程的運行結果來建立對于移植到Oracle的存儲過程的單元測試，以確保存儲過程的一致，不過對于存儲過程的單元測試好像還沒找到什么好的工具，大家能否推薦下，另外就是和解決第1個問題同樣的問題，如何保證測試數據和正式數據的隔離，但又能保證通過測試后在正式的環境下是肯定一致的。
最后還是得運行自動的業務測試，確保數據庫的升級移植成功完成。
對于測試數據和正式數據的隔離，我目前知道的解決方法是這么兩種：
1、在移植到正式庫前先將目前的運行庫復制一份到一個新的用戶下，然后將庫移植到此用戶下，進行測試，當測試成功后再將此庫切換為正式庫，這種方法的問題呢，是運行庫得停止一段時間，否則會造成一定的問題。
2、另外一種做法就是采用內存庫的方法，但這個問題是得把運行庫的數據也放進去。
保證測試數據和運行數據的隔離對于不斷的升級運行系統是很重要的。
測試驅動和持續集成是敏捷最佳實踐指導中的很關鍵的兩個要素，而在這樣的場景中就很明顯的體現出了它的好處，不知道大家對于以上兩個問題是否有更好的建議呢？