問題：
最近的項目經常需要做版本發布，但是版本發布老是出現問題，問題如下：
比如，新手小接了一個新需求，一個功能開發完了，在本地環境和測試環境都測試通過了，
把版本更新包提交到運維或者一線開發手上，
發布到線上，
通知開發，測試人員進行功能更新的確認；
如果確認ok，更新結束；
如果確認不ok，進入下面的循環；
while(線上測試確認結果不OK)
｛
//溫習下開發的功能的流程
//在出錯的代碼行前后加上日志
//部署到線上
//測試確認？OK:NO;
if(OK) break;
else {
//查看日志
//重新進入循環
}
｝
總之，相當的繁瑣；
思考： 這是一個版本發布不規范引起的問題，問題的根源在哪呢？
在下認為，原因有2；
- 本地環境，測試環境，生成環境的代碼（除了數據庫配置文件，緩存配置文件），存在差異；
- 相關的錯誤信息沒有放到容易查看的位置，出現問題無法直觀明顯的看出問題，從問題中的加日志可以看出，這是一種很低效率的方法；
解決方案：
針對這種現象和產生這種問題的原因，解決方案非常簡單；
1，首先是代碼錯誤信息的整理，最好是在數據庫中弄一張或者若干張日志表，當程序發生錯誤或者異常，或者功能邏輯錯誤的時候，把相關的判斷結論和異常信息，數據進行存庫，如果出現問題，可以快速的找到產生問題的原因，和依據；
這點非常重要，可以大大減輕開發人員成為救火隊長的壓力，把相關的權限在后台開發給業務人員，讓他們自己去協調解決問題；
2，版本控制工具的使用，比如svn， 首先，在本地弄一個功能完全覆蓋的測試，通過之后把源碼分別發布到測試環境，正式環境（數據庫配置文件，緩存配置文件除外），打出一個分支來作為一個主分支；
后續的功能開發，在這個主分支上復制出一個來進行開發，開發完成，測試環境測試完之后，合並到主分支上去，通過文件比較，找出更新的文件列表；
把這些文件整理，更新到線上，進行版本發布；
3，更新的一個好習慣；
首先有一個主目錄， 名稱是 站點域名或者應用名_時間_開發人員_需求名稱
然后里面是3個目錄，作用分別是：
| 序號 | 目錄名或者文件名 | 作用 |
| 1 | bak | 備份目錄，里面分為all(全部備份),sub(部分備份) |
| 2 | program | 按照程序的部分備份目錄，進行部分文件的替換 |
| 3 | sql | 需求需要sql腳本 |
| 4 | readme.txt | 更新的說明，文件列表，驗證方法 |
這些文件准備好之后，進行兩次對比；
一個是全部備份跟本地源碼或者運行包的對比，這可以找出是否有文件遺漏的情況出現；
第二個是部分備份跟program的更新文件進行對比，查看修改的地方，再次進行確認；
如果對比都沒有問題，直接把program目錄整個覆蓋到線上的程序目錄；
最后是按照確認步驟，讓測試和開發人員進行確認；
如果沒問題，則更新完畢；
這樣做下來，一般都不會出現版本更新的問題；
若有想法，歡迎交流；卡特 505847426