自動化持續(xù)部署是業(yè)界最佳實踐，以此為目標，能優(yōu)化IT模式。
在接觸的很多企業(yè)中，持續(xù)部署實踐依然還有很多不足，基本上部署靠人，更別談自動化了。我一直強調持續(xù)部署是IT交付的核心能力，直接關聯(lián)到研發(fā)/測試和運維多個團隊，可以成為一個運維的核心平臺。自動化部署能力的高與低，能映射出IT能力的諸多方面的問題，比如說流程上/環(huán)境管理上/服務耦合上/平臺能力上等等。
個人已經(jīng)做了三個持續(xù)部署系統(tǒng)，每做一個持續(xù)部署系統(tǒng)都給整個IT團隊帶來巨大的收益。當帶著這些經(jīng)歷再回過頭去看《持續(xù)交付》這本書的時候，書中的很多觀點讓我感觸很多，基本上每個點都有自己的感受。
讓我們來看看《持續(xù)交付》中總結的很多錯誤的模式，這些錯誤的模式的確是現(xiàn)實存在的，且必須要避免的，稱之為反模式，具體如下：
一、反模式1:手工部署軟件
對于現(xiàn)在的大多數(shù)應用程序來說，無論規(guī)模大小，其部署過程都比較復雜，而且包含很多非常靈活的部分。許多組織都使用手工方式發(fā)布軟件，也就是說部署應用程序所需的步驟是獨立的原子性操作，由某個人或某個小組來分別執(zhí)行。每個步驟里都有一些需要人為判斷的事情，因此很容易發(fā)生人為錯誤。即便不是這樣，這些步驟的執(zhí)行順序和時機的不同也會導致結果的差異性，而這種差異性很可能給我們帶來不良后果。這種反模式的特征如下：
◆有一份非常詳盡的文檔，該文檔描述了執(zhí)行步驟及每個步驟中易出錯的地方。
◆以手工測試來確認該應用程序是否運行正確。
◆在發(fā)布當天開發(fā)團隊頻繁地接到電話，客戶要求解釋部署為何會出錯。
◆在發(fā)布時，常常會修正一些在發(fā)布過程中發(fā)現(xiàn)的問題。
◆如果是集群環(huán)境部署，常常發(fā)現(xiàn)在集群中各環(huán)境的配置都不相同，比如應用服務器的連接池設置不同或文件系統(tǒng)有不同的目錄結構等。
◆發(fā)布過程需要較長的時間(超過幾分鐘)。
◆發(fā)布結果不可預測，常常不得不回滾或遇到不可預見的問題。
◆發(fā)布之后凌晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想著怎么讓剛剛部署的應用程序能夠正常工作。
相反，隨著時間的推移，部署應該走向完全自動化，即對于那些負責將應用程序部署到開發(fā)環(huán)境、測試環(huán)境或生產環(huán)境的人來說，應該只需要做兩件事：(1)挑選版本及需要部署的環(huán)境；(2)按一下“部署”按鈕。對于套裝軟件的發(fā)布來說，還應該有一個創(chuàng)建安裝程序的自動化過程。
當然，并不是所有的人都熱衷于這個想法。那么，我們先來解釋一下為什么把自動化部署看做是一個必不可少的目標。
◆如果部署過程沒有完全自動化，每次部署時都會發(fā)生錯誤。唯一的問題就是“該問題嚴重與否”而已。即便使用良好的部署測試，有些錯誤也很難追查。
◆如果部署過程不是自動化的，那么它就既不可重復也不可靠，就會在調試部署錯誤的過程中浪費很多時間。
◆手動部署流程不得不被寫在文檔里。可是文檔維護是一項復雜而費時的任務，它涉及多人之間的協(xié)作，因此文檔通常要么是不完整的，要么就是未及時更新的，而把一套自動化部署腳本作為文檔，它就永遠是最新且完整的，否則就無法進行部署工作了。
◆自動部署本質上也是鼓勵協(xié)作的，因為所有內容都在一個腳本里，一覽無遺。要讀懂文檔通常需要讀者具備一定的知識水平。然而在現(xiàn)實中，文檔通常只是為執(zhí)行部署者寫的備忘錄，是難以被他人理解的。
◆以上幾點引起的一個必然結果：手工部署過程依賴于部署專家。如果專家去度假或離職了，那你就有麻煩了。
◆盡管手工部署枯燥且極具重復性，但仍需要有相當程度的專業(yè)知識。若要求專家做這些無聊、重復，但有技術要求的任務則必定會出現(xiàn)各種我們可以預料到的人為失誤，同時失眠，酗酒這種問題也會接踵而至。然而自動化部署可以把那些成本高昂的資深高技術人員從過度工作中解放出來，讓他們投身于更高價值的工作活動當中。
◆對手工部署過程進行測試的唯一方法就是原封不動地做一次(或者幾次)。這往往費時，還會造成高昂的金錢成本，而測試自動化的部署過程卻是既便宜又容易。
◆另外，還有一種說法：自動化過程不如手工過程的可審計性好。我們對這個觀點感到很疑惑。對于一個手工過程來說，沒人能確保其執(zhí)行者會非常嚴格地遵循文檔完成操作。只有自動化過程是完全可審核的。有什么會比一個可工作的部署腳本更容易被審核的呢?
◆每個人都應該使用自動化部署過程，而且它應該是軟件部署的唯一方式。這個準則可以確保：在需要部署時，部署腳本就能完成工作。我們會提到多個原則，而其中之一就是“使用相同的腳本將軟件部署到各種環(huán)境上”。如果使用相同的腳本將軟件部署到各類環(huán)境中，那么在發(fā)布當天需要向生產環(huán)境進行部署時，這個腳本已經(jīng)被驗證過成百上千次了。如果發(fā)布時出現(xiàn)任何問題的話，你可以百分百地確定是該環(huán)境的具體配置問題，而不是這個腳本的問題。
當然，手工密集型的發(fā)布工作有時也會進行得非常順利。有沒有可能是糟糕的情況剛巧都被我們撞見了呢?假如在整個軟件生產過程中它還算不上一個易出錯的步驟，那么為什么還總要這么嚴陣以待呢?為什么需要這些流程和文檔呢?為什么團隊在周末還要加班呢?為什么還要求大家原地待命，以防意外發(fā)生呢?
二、反模式2:開發(fā)完成之后才向類生產環(huán)境部署
在這一模式下，當軟件被第一次部署到類生產環(huán)境(比如試運行環(huán)境)時，就是大部分開發(fā)工作完成時，至少是開發(fā)團隊認為“該軟件開發(fā)完成了”。這種模式中，經(jīng)常出現(xiàn)下面這些情況：
◆如果測試人員一直參與了在此之前的過程，那么他們已在開發(fā)機器上對軟件進行了測試。
◆只有在向試運行環(huán)境部署時，運維人員才第一次接觸到這個新應用程序。在某些組織中，通常是由獨立的運維團隊負責將應用程序部署到試運行環(huán)境和生產環(huán)境。在這種工作方式下，運維人員只有在產品被發(fā)布到生產環(huán)境時才第一次見到這個軟件。
◆有可能由于類生產環(huán)境非常昂貴，所以權限控制嚴格，操作人員自己無權對該環(huán)境進行操作，也有可能環(huán)境沒有按時準備好，甚至也可能根本沒人去準備環(huán)境。
◆開發(fā)團隊將正確的安裝程序、配置文件、數(shù)據(jù)庫遷移腳本和部署文檔一同交給那些真正執(zhí)行部署任務的人員，而所有這些都沒有在類生產環(huán)境或試運行環(huán)境中進行過測試。
◆開發(fā)團隊和真正執(zhí)行部署任務的人員之間的協(xié)作非常少。
每當需要將軟件部署到試運行環(huán)境時，都要組建一個團隊來完成這項任務，有時候這個團隊是一個全功能團隊，然而在大型組織中，這種部署責任通常落在多個分立的團隊肩上。
一旦將應用程序部署到了試運行環(huán)境，我們常常會發(fā)現(xiàn)新的缺陷。遺憾的是，我們常常沒有時間修復所有問題，因為最后期限馬上就到了，而且項目進行到這個階段時，推遲發(fā)布日期是不能被人接受的。所以，大多數(shù)嚴重缺陷被匆忙修復，而為了安全起見，項目經(jīng)理會保存一份已知缺陷列表，可是當下一次發(fā)布開始時，這些缺陷的優(yōu)先級還是常常被排得很低。
有的時候，情況會比這還糟，以下這些事情會使與發(fā)布相關的問題惡化：
◆假如一個應用程序是全新開發(fā)的，那么第一次將它部署到試運行環(huán)境時，可能會非常棘手。
◆發(fā)布周期越長，開發(fā)團隊在部署前作出錯誤假設的時間就越長，修復這些問題的時間也就越長。
◆交付過程被劃分到開發(fā)、DBA、運維、測試等部門的那些大型組織中，各部門之間的協(xié)作成本可能會非常高，有時甚至會將發(fā)布過程拖上“地獄列車”。此時為了完成某個部署任務(更糟糕的情況是為了解決部署過程中出現(xiàn)的問題)，開發(fā)人員、測試人員和運維人員總是高舉著問題單(不斷地互發(fā)電子郵件)。
◆開發(fā)環(huán)境與生產環(huán)境差異性越大，開發(fā)過程中所做的那些假設與現(xiàn)實之間的差距就越大。雖然很難量化，但我敢說，如果在Windows系統(tǒng)上開發(fā)軟件，而最終要部署在Solaris集群上，那么你會遇到很多意想不到的事情。
◆如果應用程序是由用戶自行安裝的(你可能沒有太多權限來對用戶的環(huán)境進行操作)，或者其中的某些組件不在企業(yè)控制范圍之內，此時可能需要很多額外的測試工作。
三、反模式3：生產環(huán)境的手工配置管理
很多組織通過專門的運維團隊來管理生產環(huán)境的配置。如果需要修改一些東西，比如修改數(shù)據(jù)庫的連接配置或者增加應用服務器線程池中的線程數(shù)，就由這個團隊登錄到生產服務器上進行手工修改。如果把這樣一個修改記錄下來，那么就相當于是變更管理數(shù)據(jù)庫中的一條記錄了。這種反模式的特征如下：
◆多次部署到試運行環(huán)境都非常成功，但當部署到生產環(huán)境時就失敗。
◆集群中各節(jié)點的行為有所不同。例如，與其他節(jié)點相比，某個節(jié)點所承擔的負載少一些，或者處理請求的時間花得多一些。
◆運維團隊需要較長時間為每次發(fā)布準備環(huán)境。
◆系統(tǒng)無法回滾到之前部署的某個配置，這些配置包括操作系統(tǒng)、應用服務器、關系型數(shù)據(jù)庫管理系統(tǒng)、Web服務器或其他基礎設施設置。
◆不知道從什么時候起，集群中的某些服務器所用的操作系統(tǒng)、第三方基礎設施、依賴庫的版本或補丁級別就不同了。
◆直接修改生產環(huán)境上的配置來改變系統(tǒng)配置。
運維的關鍵實踐之一就是配置管理，其責任之一就是讓你能夠重復地創(chuàng)建那些你開發(fā)的應用程序所依賴的每個基礎設施。這意味著操作系統(tǒng)、補丁級別、操作系 統(tǒng)配置、應用程序所依賴的其他軟件及其配置、基礎設施的配置等都應該處于受控狀態(tài)。你應該具有重建生產環(huán)境的能力，最好是能通過自動化的方式重建生產環(huán)境。
我們也應該有能力在部署出錯時，通過同一個自動化過程將系統(tǒng)回滾到之前的版本。
四、問題的自動化部署
實現(xiàn)一個完善的自動構建、部署、測試和發(fā)布系統(tǒng)。為了讓這個系統(tǒng)能夠良好運行下去，我們還幫助他們采用了一些必要的開發(fā)實踐和技術(大系統(tǒng)做小/維服務/灰度能力等等)。如何使用部署流水線，將高度自動化的測試和部署以及全面的配置管理結合在一起，實現(xiàn)一鍵式軟件發(fā)布。也就是說，只需要點擊一下鼠標，就可以將軟件部署到任何目標環(huán)境，包括開發(fā)環(huán)境、測試環(huán)境或生產環(huán)境。
——————以上觀點摘自《持續(xù)交付》
見到的通行做法是三種：
1.自動化腳本來封裝，用expect+ssh；
2.用配置管理工具來實現(xiàn)；
3.在Jenkins中寫插件來實現(xiàn)。
但我依然覺得，這不是我要的可視化+自動化部署系統(tǒng)，一般都選擇自己實現(xiàn)。
1.YY包部署系統(tǒng)
缺點：
A、對配置管理支持的不是很好
B、環(huán)境管理能力很弱
C、沒有以應用維度進行管理
2.UC的持續(xù)部署系統(tǒng)
這是利用公司另外一個系統(tǒng)基礎上修改過來的，支持了游戲業(yè)務的特殊發(fā)布場景，做了一些優(yōu)化，但還是有一些缺點。
缺點：
A、應用程序和底層Agent的耦合太重，Agent的異常會影響應用程序的工作。
B、系統(tǒng)架構設計很復雜，涉及組件過多，基于CF修改過來的。
C、基于CF的PAAS平臺每支持一種語言就要重新開發(fā)。
D、對于包的抽象能力不夠，管理能力需要在Agent層封裝。當然這個能力可以更上層實現(xiàn)，兼容各種操作場景。
3.新持續(xù)部署系統(tǒng)(doing)
基于包的全新抽象，支持各種語言；開放包的管理能力給用戶，適應各種場景；支持對包/配置/環(huán)境的可視化管理；支持灰度，支持快速回滾....等等。
【編輯推薦】
