自動化持續部署的三種反模式及解決方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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