持續集成之“自動化部署”

　　在前文《依賴管理》中，我們討論了如何在代碼變得龐大，組件增多的情況下，做好外部庫和內部組件依賴管理，從而提高構建效率?？梢詰玫膶嵺`包括：一次生成，多次復用;建立統一制品庫，外部依賴庫可以使用像Maven或Ivy這樣的工具進行統一管理;對架構進行調整，使一個大的代碼庫分成多個組件;每個組件有自己的持續集成體系;對多個組件做持續集成。然而，解決一個問題后，總會有另一個問題等在那里，需要你來解決。這次Joe的團隊遇到了部署問題。

　　星期一早上，Alice一進辦公室，就看到一臉倦意的Joe坐在椅子上，喝著咖啡。

　　“今天怎么來得這么早?看樣子，你沒睡好啊?”Alice問道。

　　“當然啦，昨天晚上我就來了。”Joe無精打采地回答道。

　　“怎么啦?”

　　“還不是因為新版本上線出了點兒問題”，Joe說道。“看來我們要把部署這件事好好討論一下，再這樣下去，不只我要來，你們也要和我一樣啦!呵呵!”

　　當天下午，Joe邀請了運維團隊的主要負責人Tom和Steven，召開了一個關于部署問題的討論會。

　　Joe說道：“先請運維部門的Tom介紹一下上周末的新版本上線過程和發現的問題吧。”

　　Tom描述了上線部署全過程。

　　不可重復且不可靠、易出錯的手工部署過程

　　當新版本開發測試完成后，由開發團隊的成員在瀏覽器上登錄運維平臺，填寫上線申請單。申請單的內容包括新版本的上線部署步驟。

　　測試人員為了保證能夠升級部署成功，首先要復制生產環境中的程序和數據到本地的測試環境中，然后根據上線申請單中所描述的上線部署步驟進行操作，對上線步驟進行驗證。

　　運維人員登錄到運維平臺，收到上線申請單后，確認“已收到”。

　　運維人員發現上線部署步驟有問題，生產環境的路徑與上線部署步驟中描述的不一致。于是與開發人員進行溝通，讓開發人員修改上線部署步驟。

　　開發人員修改后，再次通知測試人員和運維人員查看并確認。

　　確認無誤后，運維人員根據部署計劃，登錄到生產環境中，依照上線部署步驟，手工操作完成。

　　“上周末上線部署時出現的情況是：在本次部署之前，我們的集群中，有兩臺機器因HotFix，其程序配置被修改過，與其它機器不一致。因此，該機器上的部署失敗，導致部分服務不可用。運維人員查了很長時間沒有發現問題，星期日打電話把Joe叫來幫助我們查問題時，Joe才回憶起有那么一次HotFix，但當時負責的運維人員已經離職，沒人其它運維人員知道這件事情。”Tom說道，“我們對問題進行了分析，認為應該加強我們的上線流程管理，對于那種HotFix也應該發起一個審批流程，并且在該流程中不但要主要負責人審批，而且要對相關人發出周知通報。另外，我們的運維人員應該對上線單進行嚴格審核，并對部署中所涉及的機器進行更詳細的驗證，對生產環境中的任何修改都要進行登記。即使非常緊急，也要在事后補充記錄一下。”

　　“這些方法固然很好，但其實我們可以采用更好的辦法來解決。”Joe接著說到，“假如我們在部署運維工作也能夠借鑒持續集成的做法，利用一些最佳實踐，那么這次部署事故根本就不會發生。比如(1)將部署操作腳本化;(2)進行持續部署驗證測試;(3)部署腳本通用化，環境變量等使用配置方式傳入;(4)讓測試環境盡可能與生產環境一致，至少在成本條件允許的情況下盡量保持相似;(5)對環境配置進行版本控制;(6)任何人不得直接對生產環境進行直接的手工操作，等等。”

　　將部署操作腳本化，并進行部署驗證測試

　　Bob說道：“嗯，其實那些上線步驟中所描述的內容都可以進行腳本化，之前也討論過這一問題。目前上線步驟中的內容基本都可以寫成自動化腳本，即使現在不行，也可以通過少量改造，使其可以自動化。但問題是... ...”Bob猶豫了一下，接著說道，“如何來驗證這些腳本是正確的呢?”

　　Joe 說道：“保證運維人員是如何驗證上線申請單上的上線步驟是正確的呢?同樣，我們也可以做一些部署驗證就行了。這些部署的驗證也可以通過腳本方式來進行，比如在安裝之前驗證程序所用端口沒有被占用，安裝之后驗證該端口已被該程序所使用;比如安裝之前驗證程序日志中記錄了該程序已停止運行，在安裝之后驗證程序日志中刻錄該程序已重新啟動;等等”。

　　Alice問道：“那我們還要調試這些部署腳本呀?沒有線上生產環境，我們怎么調試呢?”

　　各類環境盡可能相似，并使部署腳本通用化

　　Joe 回答道：“首先我們應該加強基礎設施這方面的投入。在力所能及的情況下，讓測試環境與生產環境相似。比如，生產環境可能有100臺機器的集群，那我們至少要找兩臺機器的集群做測試環境。生產環境中使用Tomcat，我們的測試環境和開發環境中也應該使用相同的Tomcat，而不用Jetty。”

　　Joe 停下來，喝了一口咖啡，接著說道：“這樣一來，我們的部署腳本就可以在開發環境、測試環境進行測試了。當開發人員進行本地測試時，可以使用這個腳本進行單機的部署。當測試人員進行集成測試時，可以使用同樣的腳本進行多機部署。與機器數量無關的配置可以統一放在某配置文件中。而與機器數量等相關的配置可以放在另外的配置文件中。由于在真正上線部署之前，開發人員和測試人員已經使用同一個腳本進行多次部署，就是對該腳本進行的測試。當我們上線部署時，只有與機器相關的配置文件會有變化，其它配置基本相同，所以上線部署時腳本出錯的幾率已經比較小了。而且，這種自動化沒有人工干預，也不會發生手工誤操作。”

　　Tom問道：“那這些腳本由誰來寫?由誰維護呢?”

　　Joe回答道：“誰最了解情況，就由誰來寫。其實，我們也應該像對待產品代碼一樣，來對待這些腳本和配置文件，把它們放在我們的代碼庫里，進行版本控制。無論是運維人員還是開發人員，或者測試人員，對這些腳本的修改都應該提交到版本控制庫中，除非他所做的修改只是為了測試他自己在本地的程序，那就不用提交了。這樣一來，‘誰在什么時候對什么進行了修改，為什么做修改?’這個審計問題就可以直接由版本控制系統來回答，也就做到了所有內容可追蹤了。”

原文轉自：http://www.anti-gravitydesign.com