走向“持續部署”(2)

　　2. 盡可能短的測試反饋時間

　　盡管測試數量較大，測試的絕對運行時間較長，但結合Cruise本身提供的并行運行特性，團隊成員胡凱，Derek和李彥輝自行開發的測試負載均衡工具(Test-load-balancer)將所有測試分成若干份，Cruise將其分配到Agent集群中同時運行，使單元測試或其它測試在可接受的相對時間內完成(單元測試在15分鐘之內，功能測試在30分鐘之內)。近期還將增加數個Agent，以便繼續縮短測試需要的時間。

　　3. 部署過程自動化

　　當部署復雜軟件時，都會使用人工過程，而且可能會花上幾天的時間。而這種部署過程通常比較復雜，而且很難可靠地重復操作。因此，人們會寫一些文檔幫助這一過程，但文檔常常更新不及時。有時，還需要幾個關鍵性人物同時在場才能完成。

　　當每次由不同的人員進行部署操作時，出錯的概率就增加，所以要盡可能少的人工步驟。

　　在Cruise的Pipeline中，盡管由人來觸發兩個環境中的部署，但部署過程本身是自動化的。在部署過程中，Cruise的安裝包會自動關閉服務器，更新自身程序和升級數據庫，然后再重新啟動。所有的Agent也會以Server為準，自動更新到與其相同的版本，而不必人工去升級每個 Agent(每次為70個Agent的手動升級也是很大的成本，所以我們做了自動升級這個特性)。

　　4. 部署過程要保證數據安全

　　如果因為持續部署而導致數據丟失或錯誤，會得不償失。所以，我們每次修改數據庫結構或配置文件的結構后，都會寫出相應的遷移腳本，并在部署過程中運行。

　　目前我們使用由Thoughtworkers開發的開源項目DBDeploy來做數據庫升級。對于XML配置文件的修改，我們也自行開發了一個遷移框架。

　　5. 在穩定的前提下，盡早部署

　　有人會問：“為什么要持續部署?你又如何知道部署的版本是否穩定呢?宕機了怎么辦?”的確，沒有哪個開發人員希望持續集成服務器在工作時間內宕機。盡管我們無法百分之百確保每個部署版本都穩定，但在可預見的范圍內穩定就可以了，否則我們就無法解決“最后一哩”問題。

　　Cruise在最初三個迭代(迭代時間為一個星期)后，就開始用Cruise來做自己的持續集成服務器了(即UAT環境)。我們讓它在UAT環境上 運行了兩周，沒有發現什么問題，說明版本相對穩定，就將它部署到“Production”環境上了。在那以后，隨著用戶的增多，很多人認為由于部署失敗而 導致持續集成服務器宕機的風險要高于那些新特性和修復的缺陷。因此，我們的客戶要求新版本部署至 “Production”環境之前，一定要在UAT環境上運行。目前，Cruise部署到UAT環境的頻率不固定(一般為兩天至一周)，而部署到 Production環境的頻率為一周。也就是說，Production環境上的版本要落后于UAT一周的時間。

　　6. 完善的風險緩解措施

　　隨著項目的進行，難免會有部署失敗的情況，所以一定要有風險緩解措施。例如：

　　(1) 部署盡可能在用戶少的時候;(2) 部署時必須有技術人員在場;(2) 每次部署前備份原始數據;(3) 時刻準備回滾腳本。

　　7. 將同樣的產物部署到不同的環境中

　　讓你的產品可以部署到不同的環境中，如果這些環境的環境配置不同，則把有關環境配置的內容排除在你的產品之外。如果你有很多個配置變量，請讓這些配置保存在同一處，而且有默認值。

　　基于這一原則，Cruise唯一的配置就是XML文件。

　　8. 不斷的反思與重構

　　這一點就沒有什么可說的了。它適用于所有的活動。

　　小結

　　實踐表明，建立自動化部署管道的益處很多。在過去的幾年中，ThoughtWorks利用這一方法幫助很多項目組和公司解決了他們的“最后一哩”問題。例如，在某項目中，通過自動化部署過程，使部署頻率從幾天一次提高到每天一次，而且該過程耗時少于15中分鐘(其僅有一分鐘的停機時間)。這對軟件整個生命周期的交付階段有著積極作用，只要按下鼠標就可以準備好所需要測試環境，從而減少了人為失誤造成的不必要的損失，顯著降低軟件發布的風險。另外，頻繁且輕松的發布讓開發人員全神貫注于他們想做的事情：開發新的功能。

原文轉自：http://kb.cnblogs.com/page/157115/