自動化持續部署是業界最佳實踐，以此為目标，能優化it模式。
在接觸的很多企業中，持續部署實踐依然還有很多不足，基本上部署靠人，更别談自動化了。我一直強調持續部署是it傳遞的核心能力，直接關聯到研發/測試和運維多個團隊，可以成為一個運維的核心平台。自動化部署能力的高與低，能映射出it能力的諸多方面的問題，比如說流程上/環境管理上/服務耦合上/平台能力上等等。
個人已經做了三個持續部署系統，每做一個持續部署系統都給整個it團隊帶來巨大的收益。當帶着這些經曆再回過頭去看《持續傳遞》這本書的時候，書中的很多觀點讓我感觸很多，基本上每個點都有自己的感受。
讓我們來看看《持續傳遞》中總結的很多錯誤的模式，這些錯誤的模式的确是現實存在的，且必須要避免的，稱之為反模式，具體如下：
一、反模式1:手工部署軟體
對于現在的大多數應用程式來說，無論規模大小，其部署過程都比較複雜，而且包含很多非常靈活的部分。許多組織都使用手工方式釋出軟體，也就是說部署應用程式所需的步驟是獨立的原子性操作，由某個人或某個小組來分别執行。每個步驟裡都有一些需要人為判斷的事情，是以很容易發生人為錯誤。即便不是這樣，這些步驟的執行順序和時機的不同也會導緻結果的差異性，而這種差異性很可能給我們帶來不良後果。這種反模式的特征如下：
◆有一份非常詳盡的文檔，該文檔描述了執行步驟及每個步驟中易出錯的地方。
◆以手工測試來确認該應用程式是否運作正确。
◆在釋出當天開發團隊頻繁地接到電話，客戶要求解釋部署為何會出錯。
◆在釋出時，常常會修正一些在釋出過程中發現的問題。
◆如果是叢集環境部署，常常發現在叢集中各環境的配置都不相同，比如應用伺服器的連接配接池設定不同或檔案系統有不同的目錄結構等。
◆釋出過程需要較長的時間(超過幾分鐘)。
◆釋出結果不可預測，常常不得不復原或遇到不可預見的問題。
◆釋出之後淩晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想着怎麼讓剛剛部署的應用程式能夠正常工作。
相反，随着時間的推移，部署應該走向完全自動化，即對于那些負責将應用程式部署到開發環境、測試環境或生産環境的人來說，應該隻需要做兩件事：(1)挑選版本及需要部署的環境；(2)按一下“部署”按鈕。對于套裝軟體的釋出來說，還應該有一個建立安裝程式的自動化過程。
當然，并不是所有的人都熱衷于這個想法。那麼，我們先來解釋一下為什麼把自動化部署看做是一個必不可少的目标。
◆如果部署過程沒有完全自動化，每次部署時都會發生錯誤。唯一的問題就是“該問題嚴重與否”而已。即便使用良好的部署測試，有些錯誤也很難追查。
◆如果部署過程不是自動化的，那麼它就既不可重複也不可靠，就會在調試部署錯誤的過程中浪費很多時間。
◆手動部署流程不得不被寫在文檔裡。可是文檔維護是一項複雜而費時的任務，它涉及多人之間的協作，是以文檔通常要麼是不完整的，要麼就是未及時更新的，而把一套自動化部署腳本作為文檔，它就永遠是最新且完整的，否則就無法進行部署工作了。
◆自動部署本質上也是鼓勵協作的，因為所有内容都在一個腳本裡，一覽無遺。要讀懂文檔通常需要讀者具備一定的知識水準。然而在現實中，文檔通常隻是為執行部署者寫的備忘錄，是難以被他人了解的。
◆以上幾點引起的一個必然結果：手工部署過程依賴于部署專家。如果專家去度假或離職了，那你就有麻煩了。
◆盡管手工部署枯燥且極具重複性，但仍需要有相當程度的專業知識。若要求專家做這些無聊、重複，但有技術要求的任務則必定會出現各種我們可以預料到的人為失誤，同時失眠，酗酒這種問題也會接踵而至。然而自動化部署可以把那些成本高昂的資深高技術人員從過度工作中解放出來，讓他們投身于更高價值的工作活動當中。
◆對手工部署過程進行測試的唯一方法就是原封不動地做一次(或者幾次)。這往往費時，還會造成高昂的金錢成本，而測試自動化的部署過程卻是既便宜又容易。
◆另外，還有一種說法：自動化過程不如手工過程的可審計性好。我們對這個觀點感到很疑惑。對于一個手工過程來說，沒人能確定其執行者會非常嚴格地遵循文檔完成操作。隻有自動化過程是完全可稽核的。有什麼會比一個可工作的部署腳本更容易被稽核的呢?
◆每個人都應該使用自動化部署過程，而且它應該是軟體部署的唯一方式。這個準則可以確定：在需要部署時，部署腳本就能完成工作。我們會提到多個原則，而其中之一就是“使用相同的腳本将軟體部署到各種環境上”。如果使用相同的腳本将軟體部署到各類環境中，那麼在釋出當天需要向生産環境進行部署時，這個腳本已經被驗證過成百上千次了。如果釋出時出現任何問題的話，你可以百分百地确定是該環境的具體配置問題，而不是這個腳本的問題。
當然，手工密集型的釋出工作有時也會進行得非常順利。有沒有可能是糟糕的情況剛巧都被我們撞見了呢?假如在整個軟體生産過程中它還算不上一個易出錯的步驟，那麼為什麼還總要這麼嚴陣以待呢?為什麼需要這些流程和文檔呢?為什麼團隊在周末還要加班呢?為什麼還要求大家原地待命，以防意外發生呢?
二、反模式2:開發完成之後才向類生産環境部署
在這一模式下，當軟體被第一次部署到類生産環境(比如試運作環境)時，就是大部分開發工作完成時，至少是開發團隊認為“該軟體開發完成了”。這種模式中，經常出現下面這些情況：
◆如果測試人員一直參與了在此之前的過程，那麼他們已在開發機器上對軟體進行了測試。
◆隻有在向試運作環境部署時，運維人員才第一次接觸到這個新應用程式。在某些組織中，通常是由獨立的運維團隊負責将應用程式部署到試運作環境和生産環境。在這種工作方式下，運維人員隻有在産品被釋出到生産環境時才第一次見到這個軟體。
◆有可能由于類生産環境非常昂貴，是以權限控制嚴格，操作人員自己無權對該環境進行操作，也有可能環境沒有按時準備好，甚至也可能根本沒人去準備環境。
◆開發團隊将正确的安裝程式、配置檔案、資料庫遷移腳本和部署文檔一同交給那些真正執行部署任務的人員，而所有這些都沒有在類生産環境或試運作環境中進行過測試。
◆開發團隊和真正執行部署任務的人員之間的協作非常少。
每當需要将軟體部署到試運作環境時，都要組建一個團隊來完成這項任務，有時候這個團隊是一個全功能團隊，然而在大型組織中，這種部署責任通常落在多個分立的團隊肩上。
一旦将應用程式部署到了試運作環境，我們常常會發現新的缺陷。遺憾的是，我們常常沒有時間修複所有問題，因為最後期限馬上就到了，而且項目進行到這個階段時，推遲釋出日期是不能被人接受的。是以，大多數嚴重缺陷被匆忙修複，而為了安全起見，項目經理會儲存一份已知缺陷清單，可是當下一次釋出開始時，這些缺陷的優先級還是常常被排得很低。
有的時候，情況會比這還糟，以下這些事情會使與釋出相關的問題惡化：
◆假如一個應用程式是全新開發的，那麼第一次将它部署到試運作環境時，可能會非常棘手。
◆釋出周期越長，開發團隊在部署前作出錯誤假設的時間就越長，修複這些問題的時間也就越長。
◆傳遞過程被劃分到開發、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)
基于包的全新抽象，支援各種語言；開放包的管理能力給使用者，适應各種場景；支援對包/配置/環境的可視化管理；支援灰階，支援快速復原....等等。
作者：老王
來源：51cto