在上家公司做運維時，接觸到了代碼管理和版本的發布工作。當時的公司剛成立，IT人員非常的少，總共五個人（包括UI設計，開發，運維）帶著20個左右的外包。回想當時真是我工作7年中最痛苦的日子。

       當時開發速度非常快，幾乎每天都有版本上線發布，開發把svn的代碼管理，編譯，測試環境部署都丟給了運維。開始是每個開發把修改代碼提交到svn，通過郵件告知修改了哪些內容，然后運維從svn上逐個取到本地后編譯。整個svn上的代碼非常不穩定，我只能盡量的保證自己本地環境是穩定的，以便用來發布。后來根據根據開發提供的列表通過寫dos命令抽取后編譯，這樣快速了一點，再后來隨著對svn的了解自己寫了shell腳本通過svn的鉤子記錄開發提供的代碼文件，自動從svn取下后通過ant編譯。雖然簡單了很多，但是經常出現要上線的代碼與不上線的代碼混合到一起，或者生產出現了緊急問題需要修復時找不到與生產環境匹配的代碼庫，只能取單個文件修改后單個更新。由于當時自己不做開發，未能深入了解到svn的使用，反復思考還是未能找到最好的解決方式。最近重新去網上看了下svn的代碼管理和自動發布系統的思想后，清楚了當時存在的問題和解決方式。

當時的錯誤點：

1、當時發布版本太隨意，無任何版本計劃

2、只依靠svn對版本的管理，未能考慮開發提交規范

3、對應用并行開發，未能利用svn的主干、分值、版本庫概念

4、通過復雜易錯的增量發布，未能采用打包全量發布

    對于互聯網應用系統失效性要求高，版本發布頻繁，發布過程盡量對用戶無影響。使用傳統應用中的手工打包，手工發布已經無法滿足需要。目前大家都在推出自動部署概念。但是在自動部署建設中最難的就是代碼的管理工作，如果源代碼沒有好的管理部署到系統會出現各種問題，例如最煩惱的代碼疊加到一起。svn，git雖然是很好的源碼管理工具，單并不意味著大家可以隨意提交無任何規范。工具只是幫助我們更好的工作，還需要很好的管理規范才能讓工作更好的運行。建立自動發布系統個人覺得需要有下面幾個方面的完善。

1、對開發需求安排合理的版本計劃

2、對多項目并行開發時采用主干，分支，版本庫。主干用來發布使用，分支用來并行開發后續版本或大需求使用，版本庫保存上線后的版本代碼，以便生產出現問題緊急修復時使用。

3、嚴格的開發需求編號，在鉤子中設置主干允許提交的開發需求編號，只允許提交注釋為下個版本的代碼。始終保持主干是相對穩定的版本。

4、每當版本封板后，tag出一個版本到版本庫，同時創建一個最新的分支，然后把下個版本要上線的內容從分支合并或提交到主干。

5、將配置文件、java文件、sql文件分別放到不同的文件夾中。新增配置文件和sql文件在自助發布系統中指定，配置項也在自助部署工具中填寫，發布包直接從主干取出后編譯打包。

6、每次測試完成封板時由測試負責人點擊測試完成后系統將本次要發布的配置文件，配置項，版本包存放到一個指定目錄。

7、由版本負責人審核通過后發布人員才能按計劃發布版本，在發布版本時對涉及到的生產環境配置文件和部署包進行備份。這樣方便上線后的回滾，對于sql的變更如果需要回滾只能由人工操作，不過這方面的回滾操作很少。

在沒搞清楚這些問題時怎么思考自動發布總是各種問題纏繞無法解決，相信清楚了這些自己在做自動發布時就很好實現了。