[[152807]]

自動化持續部署是業界最佳實踐，以此為目標，能優化IT模式。

　　在接觸的很多企業中，持續部署實踐依然還有很多不足，基本上部署靠人，更別談自動化了。我一直強調持續部署是IT交付的核心能力，直接關聯到研發/測試和運維多個團隊，可以成為一個運維的核心平臺。自動化部署能力的高與低，能映射出IT能力的諸多方面的問題，比如說流程上/環境管理上/服務耦合上/平臺能力上等等。

　　個人已經做了三個持續部署系統，每做一個持續部署系統都給整個IT團隊帶來巨大的收益。當帶著這些經歷再回過頭去看《持續交付》這本書的時候，書中的很多觀點讓我感觸很多，基本上每個點都有自己的感受。

　　讓我們來看看《持續交付》中總結的很多錯誤的模式，這些錯誤的模式的確是現實存在的，且必須要避免的，稱之為反模式，具體如下：

　　一、反模式1:手工部署軟件

　　對于現在的大多數應用程序來說，無論規模大小，其部署過程都比較復雜，而且包含很多非常靈活的部分。許多組織都使用手工方式發布軟件，也就是說部署應用程序所需的步驟是獨立的原子性操作，由某個人或某個小組來分別執行。每個步驟里都有一些需要人為判斷的事情，因此很容易發生人為錯誤。即便不是這樣，這些步驟的執行順序和時機的不同也會導致結果的差異性，而這種差異性很可能給我們帶來不良后果。這種反模式的特征如下：

　　◆有一份非常詳盡的文檔，該文檔描述了執行步驟及每個步驟中易出錯的地方。

　　◆以手工測試來確認該應用程序是否運行正確。

　　◆在發布當天開發團隊頻繁地接到電話，客戶要求解釋部署為何會出錯。

　　◆在發布時，常常會修正一些在發布過程中發現的問題。

　　◆如果是集群環境部署，常常發現在集群中各環境的配置都不相同，比如應用服務器的連接池設置不同或文件系統有不同的目錄結構等。

　　◆發布過程需要較長的時間(超過幾分鐘)。

　　◆發布結果不可預測，常常不得不回滾或遇到不可預見的問題。

　　◆發布之后凌晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想著怎么讓剛剛部署的應用程序能夠正常工作。

　　相反，隨著時間的推移，部署應該走向完全自動化，即對于那些負責將應用程序部署到開發環境、測試環境或生產環境的人來說，應該只需要做兩件事：(1)挑選版本及需要部署的環境；(2)按一下“部署”按鈕。對于套裝軟件的發布來說，還應該有一個創建安裝程序的自動化過程。

　　當然，并不是所有的人都熱衷于這個想法。那么，我們先來解釋一下為什么把自動化部署看做是一個必不可少的目標。

　　◆如果部署過程沒有完全自動化，每次部署時都會發生錯誤。唯一的問題就是“該問題嚴重與否”而已。即便使用良好的部署測試，有些錯誤也很難追查。

　　◆如果部署過程不是自動化的，那么它就既不可重復也不可靠，就會在調試部署錯誤的過程中浪費很多時間。

　　◆手動部署流程不得不被寫在文檔里。可是文檔維護是一項復雜而費時的任務，它涉及多人之間的協作，因此文檔通常要么是不完整的，要么就是未及時更新的，而把一套自動化部署腳本作為文檔，它就永遠是最新且完整的，否則就無法進行部署工作了。

　　◆自動部署本質上也是鼓勵協作的，因為所有內容都在一個腳本里，一覽無遺。要讀懂文檔通常需要讀者具備一定的知識水平。然而在現實中，文檔通常只是為執行部署者寫的備忘錄，是難以被他人理解的。

　　◆以上幾點引起的一個必然結果：手工部署過程依賴于部署專家。如果專家去度假或離職了，那你就有麻煩了。

　　◆盡管手工部署枯燥且極具重復性，但仍需要有相當程度的專業知識。若要求專家做這些無聊、重復，但有技術要求的任務則必定會出現各種我們可以預料到的人為失誤，同時失眠，酗酒這種問題也會接踵而至。然而自動化部署可以把那些成本高昂的資深高技術人員從過度工作中解放出來，讓他們投身于更高價值的工作活動當中。

　　◆對手工部署過程進行測試的唯一方法就是原封不動地做一次(或者幾次)。這往往費時，還會造成高昂的金錢成本，而測試自動化的部署過程卻是既便宜又容易。

　　◆另外，還有一種說法：自動化過程不如手工過程的可審計性好。我們對這個觀點感到很疑惑。對于一個手工過程來說，沒人能確保其執行者會非常嚴格地遵循文檔完成操作。只有自動化過程是完全可審核的。有什么會比一個可工作的部署腳本更容易被審核的呢?

　　◆每個人都應該使用自動化部署過程，而且它應該是軟件部署的唯一方式。這個準則可以確保：在需要部署時，部署腳本就能完成工作。我們會提到多個原則，而其中之一就是“使用相同的腳本將軟件部署到各種環境上”。如果使用相同的腳本將軟件部署到各類環境中，那么在發布當天需要向生產環境進行部署時，這個腳本已經被驗證過成百上千次了。如果發布時出現任何問題的話，你可以百分百地確定是該環境的具體配置問題，而不是這個腳本的問題。

　　當然，手工密集型的發布工作有時也會進行得非常順利。有沒有可能是糟糕的情況剛巧都被我們撞見了呢?假如在整個軟件生產過程中它還算不上一個易出錯的步驟，那么為什么還總要這么嚴陣以待呢?為什么需要這些流程和文檔呢?為什么團隊在周末還要加班呢?為什么還要求大家原地待命，以防意外發生呢?

　　二、反模式2:開發完成之后才向類生產環境部署

　　在這一模式下，當軟件被第一次部署到類生產環境(比如試運行環境)時，就是大部分開發工作完成時，至少是開發團隊認為“該軟件開發完成了”。這種模式中，經常出現下面這些情況：

　　◆如果測試人員一直參與了在此之前的過程，那么他們已在開發機器上對軟件進行了測試。

　　◆只有在向試運行環境部署時，運維人員才第一次接觸到這個新應用程序。在某些組織中，通常是由獨立的運維團隊負責將應用程序部署到試運行環境和生產環境。在這種工作方式下，運維人員只有在產品被發布到生產環境時才第一次見到這個軟件。

　　◆有可能由于類生產環境非常昂貴，所以權限控制嚴格，操作人員自己無權對該環境進行操作，也有可能環境沒有按時準備好，甚至也可能根本沒人去準備環境。

　　◆開發團隊將正確的安裝程序、配置文件、數據庫遷移腳本和部署文檔一同交給那些真正執行部署任務的人員，而所有這些都沒有在類生產環境或試運行環境中進行過測試。

　　◆開發團隊和真正執行部署任務的人員之間的協作非常少。

　　每當需要將軟件部署到試運行環境時，都要組建一個團隊來完成這項任務，有時候這個團隊是一個全功能團隊，然而在大型組織中，這種部署責任通常落在多個分立的團隊肩上。

#p#

　　一旦將應用程序部署到了試運行環境，我們常常會發現新的缺陷。遺憾的是，我們常常沒有時間修復所有問題，因為最后期限馬上就到了，而且項目進行到這個階段時，推遲發布日期是不能被人接受的。所以，大多數嚴重缺陷被匆忙修復，而為了安全起見，項目經理會保存一份已知缺陷列表，可是當下一次發布開始時，這些缺陷的優先級還是常常被排得很低。

　　有的時候，情況會比這還糟，以下這些事情會使與發布相關的問題惡化：

　　◆假如一個應用程序是全新開發的，那么第一次將它部署到試運行環境時，可能會非常棘手。

　　◆發布周期越長，開發團隊在部署前作出錯誤假設的時間就越長，修復這些問題的時間也就越長。

　　◆交付過程被劃分到開發、DBA、運維、測試等部門的那些大型組織中，各部門之間的協作成本可能會非常高，有時甚至會將發布過程拖上“地獄列車”。此時為了完成某個部署任務(更糟糕的情況是為了解決部署過程中出現的問題)，開發人員、測試人員和運維人員總是高舉著問題單(不斷地互發電子郵件)。

　　◆開發環境與生產環境差異性越大，開發過程中所做的那些假設與現實之間的差距就越大。雖然很難量化，但我敢說，如果在Windows系統上開發軟件，而最終要部署在Solaris集群上，那么你會遇到很多意想不到的事情。

　　◆如果應用程序是由用戶自行安裝的(你可能沒有太多權限來對用戶的環境進行操作)，或者其中的某些組件不在企業控制范圍之內，此時可能需要很多額外的測試工作。

　　三、反模式3：生產環境的手工配置管理

　　很多組織通過專門的運維團隊來管理生產環境的配置。如果需要修改一些東西，比如修改數據庫的連接配置或者增加應用服務器線程池中的線程數，就由這個團隊登錄到生產服務器上進行手工修改。如果把這樣一個修改記錄下來，那么就相當于是變更管理數據庫中的一條記錄了。這種反模式的特征如下：

　　◆多次部署到試運行環境都非常成功，但當部署到生產環境時就失敗。

　　◆集群中各節點的行為有所不同。例如，與其他節點相比，某個節點所承擔的負載少一些，或者處理請求的時間花得多一些。

　　◆運維團隊需要較長時間為每次發布準備環境。

　　◆系統無法回滾到之前部署的某個配置，這些配置包括操作系統、應用服務器、關系型數據庫管理系統、Web服務器或其他基礎設施設置。

　　◆不知道從什么時候起，集群中的某些服務器所用的操作系統、第三方基礎設施、依賴庫的版本或補丁級別就不同了。

　　◆直接修改生產環境上的配置來改變系統配置。

　　運維的關鍵實踐之一就是配置管理，其責任之一就是讓你能夠重復地創建那些你開發的應用程序所依賴的每個基礎設施。這意味著操作系統、補丁級別、操作系 統配置、應用程序所依賴的其他軟件及其配置、基礎設施的配置等都應該處于受控狀態。你應該具有重建生產環境的能力，最好是能通過自動化的方式重建生產環境。

　　我們也應該有能力在部署出錯時，通過同一個自動化過程將系統回滾到之前的版本。

　　四、問題的答案：自動化部署

　　實現一個完善的自動構建、部署、測試和發布系統。為了讓這個系統能夠良好運行下去，我們還幫助他們采用了一些必要的開發實踐和技術(大系統做小/維服務/灰度能力等等)。如何使用部署流水線，將高度自動化的測試和部署以及全面的配置管理結合在一起，實現一鍵式軟件發布。也就是說，只需要點擊一下鼠標，就可以將軟件部署到任何目標環境，包括開發環境、測試環境或生產環境。

　　——————以上觀點摘自《持續交付》

　　見到的通行做法是三種：

　　1.自動化腳本來封裝，用expect+ssh；

　　2.用配置管理工具來實現；

　　3.在Jenkins中寫插件來實現。

　　但我依然覺得，這不是我要的可視化+自動化部署系統，一般都選擇自己實現。

　　1.YY包部署系統

　　缺點：

　　A、對配置管理支持的不是很好

　　B、環境管理能力很弱

　　C、沒有以應用維度進行管理

　　2.UC的持續部署系統

　　這是利用公司另外一個系統基礎上修改過來的，支持了游戲業務的特殊發布場景，做了一些優化，但還是有一些缺點。

　　缺點：

　　A、應用程序和底層Agent的耦合太重，Agent的異常會影響應用程序的工作。

　　B、系統架構設計很復雜，涉及組件過多，基于CF修改過來的。

　　C、基于CF的PAAS平臺每支持一種語言就要重新開發。

　　D、對于包的抽象能力不夠，管理能力需要在Agent層封裝。當然這個能力可以更上層實現，兼容各種操作場景。

　　3.新持續部署系統(doing)

　　基于包的全新抽象，支持各種語言；開放包的管理能力給用戶，適應各種場景；支持對包/配置/環境的可視化管理；支持灰度，支持快速回滾....等等。