上一篇文章用了我２個晚上，今天把老早之前就想寫的公司持續整合的總結和展望寫了，算是給自己大腦一個交代——對自己說到做到。

持續的乾貨三大塊：

1. 程式碼管理
2. 程式碼編譯打包
3. 程式碼釋出

為了規避風險，隔離不可控因素。三大塊中又可以插入環境差異。通常是二到四個：

1. 研發環境。研發自己搞，愛怎折騰就怎麼折騰。
2. 測試環境 。測試驗證的環境，可以甲乙丙丁多個存在。
3. 生產映象環境。預釋出用，緩衝不可控因素。
4. 生產環境。顧名思義。

持續整合三大塊，通常就在1\2\3環境裡不停的迭代。最後到生產上被利用。生產迭代頻率相對低一些。

程式碼管理

公司剛建立的時候用的是SVN，那個時代我還是個小白，並沒有過多參與。後來，公司領導看git的分散式程式碼倉庫牛掰，就在觀望、學習、變革中，把程式碼管理的環境遷移到了git上面，這期間，團隊經歷了不適應，不會，抱怨，理解，能用，會用，善用的轉變。主要還是招聘到了一個git小王子，他幫助團隊對git的理解大踏步前進。廢話講完。

git工作流

從推動力上來說，研發團隊的推動力來自產品和市場。這個在寫公司srum流的文章裡有提及。
這個地方就不囉嗦git的工作流了。我們遵從了Gitflow工作流的基本邏輯。實際運用中靈活處理。
想了解git的工作流請移步github上的git-workflows-and-tutorials。

資料庫變更管理

資料庫是最難控制變更的。因此我們經過探索和總結摸索了一套較為有效的管理方式。可能還不是最科學的，雖然會有些問題，但是目前運作問題不算大。也很少看到這方面的文章。我們約定，資料庫變更以指令碼方式提交，禁止研發在測試環境自己修改資料庫，變更需提交指令碼作為依據。那麼，我在執行過程中，如測試環境A，跑了，我就會以修改資料夾名稱，以名稱為標記。如果指令碼還要再修改，則研發口頭告知或他直接提交新的變更指令碼。變更指令碼有若干個，通常以任務標號為命名規則，沒有專案標號則按自定義方式定義。
這套機制，實施最大的難度是協調，讓研發瞭解這個規則。瞭解並熟悉這套流程之後，基本就沒有什麼大問題。

編譯打包釋出測試環境

現在這一套全部指令碼化，總結就是流程是逐步完善起來的，一個階段有一個階段的做法。
開始，研發手動在本地打包，工具eclipse+maven，打包完後手動上傳到伺服器的tomcat指定目錄。那會我們只有３個專案，這麼做問題不大。
後來，總是等著研發釋出，太慢了，這麼low的重複勞動我說我來做好了，你教下我怎麼打包的，然後我就會了，我就研究了maven的一起機制。搞了那麼一週多點，由於拿到了測試伺服器的賬戶密碼，我就在想怎麼可以提高效率。研究了明白了裡面的原理，我就很自然的認為，既然本地可以打包，那伺服器上到打包拷貝過去不是更快，網路傳輸的時間就略去了。於是，我測試了下，填了很多坑，手動在伺服器上打包釋出成功。就掌握了最原始的釋出。
再後來，專案越來越多，多到大於１０個，雖然只有幾個釋出頻率很高，但是手動釋出感覺勞心費力，效率底下，我就琢磨如何提高。shell就引入。專案進度太快，我根本沒有時間利用上班時間搞，於是下班後，自己一點一點測試。把第一版的自動釋出指令碼寫出來，結合crontab 命令，每天自動釋出。然後就輕鬆多了。後來專門利用業餘時間對shell做了一個深化，就有了一次重構。
可以參考：

http://blog.csdn.net/windanchaos/article/details/53490630
現在使用的指令碼已經不是這個版本了，又被我重構了一次。由之前的一鍋貼全部發布，改進為任意專案選擇釋出，由jenkins驅動。現在的模式：自動＋手動方式。比起從前還是大大的加快了迭代測試效率。雖然還有很多問題。比如現在的不熟結構是所有專案都在一個tomcat下面，釋出一個，其實是影響全域性的。全套釋出下來，花了很多不必要的時間。
當然，還寫了很多釋出小工具，比如自動識別24小時內修改提交到程式碼庫的js/css/jsp等靜態資原始檔，巧個命令自動拷貝過去，完全不用重新打包。
還存在的問題：
１、tomcat部署在一起導致的釋出啟動效率，浪費不必要的時間。主要是系統資源不夠，沒有去拆分。
２、外網地址一週要變２－３次，需要手動去修改域名對映。浪費時間。
３、jenkins讓人人都具備釋出能力，從某種意義上來說是不恰當的。雖然解放了我，但是還是存在相互干擾的情況。不算嚴重。

釋出生產

測試完成就發生產。
這個也是一個迭代過程。迭代到目前，重要核心專案都有多個節點。服務端使用了負載均衡。負載均衡是第三方服務，目前無法指令碼自動化，所以除了核心的幾個節點外，其他指令碼釋出。
核心節點，是第三方上斷掉某節點，然後手動執行釋出。釋出後，再把節點放回去。接著另一個節點，基本上做到了熱釋出。
目前的問題：
１、手動釋出的沒有要手動做備份。
２、核心節點的手動釋出效率不敢恭維，但是得接受，因為生產，不能出事故。
３、熱修程式碼提交沒有得到控制。已經出臺提交程式碼規約去限制。
４、釋出後的驗證。

整個流程的不足和展望

１、環節上來說，缺乏自動化的測試，包含常規的程式碼檢測，核心的api自動化測試。
２、上線後，核心功能需要人肉去驗證，微信的ui自動化受阻。人肉總是不太穩定的，所以很多時候功能一多，一修改一個小地方，其他地方就受影響。
３、生產錯誤日誌，沒有很好的利用起來。現階段，我人肉去tail and grep，排查錯誤，看到有問題的直接喊研發到我那看，這個工作沒有人喊我做，但是必要。而錯誤日誌很多是沒有必要列印的，這也是一個可以優化的。

展望，就是解決不足。
１、這個不是我一個人能推動的事，需要團隊配合。
２、已有計劃推動自動化的一些使用。
３、日誌監控系統，搭一套。開源軟體。後期（很遠很遠）就是線上監控。
４、安全測試的還比較少。所以可以搞一搞，安全掃描工具。
５、程式碼的靜態掃描也要搞起來，研發現在是反感態度，空指標……
６、內網從新搭建測試環境。tomcat分開部署。