正如Kurt Bittner說的那樣，如果敏捷僅僅是個開始的話，那持續交付則是頭條！（我則更喜歡理解成高潮）。

“If Agile Was the Opening Act,Continuous Delivery is the Headliner!”——Kurt Bittner

現代企業要求軟件開發過程保持最大的工作效率，傳統的瀑布式開發早已跌入歷史洪流，甚至敏捷宣言也已超過10年的歷史，軟件開發在經歷了敏捷開發、持續集成後，正逐步邁入到持續交付的時代。

持續交付是持續集成的延伸，強調以自動化、可視化的手段更快的將產品交付到客戶手中。持續交付的一個重要衡量指標就是從代碼提交直到客戶能使用這個功能所花費的時間，通過實行持續交付，這個時間往往可以從原先的幾天、幾周縮短到幾分鐘。當然，快速交付並不意味著不可靠。

那麽我們如何實施自己的持續交付？以我們實際項目為例，與大家進行一個探討，歸納起來，總共經歷了以下3個過程：

搭建持續集成環境

以Jenkins為核心搭建持續集成平臺，每天定時從代碼庫中檢出最新的代碼進行編譯、構建。構建結果通知到項目組，開發人員只需要關註每天的集成結果是否是綠的就可以了，同時加入測試環境部署及自動化測試。

圖1.自動部署測試環境

圖2. Selenium自動測試

簡潔統一風格的代碼有利於大家更好的理解及進行走查，而單元測試則是為了前期高質量的交付。

圖3.單元測試統計

通過SonarQube+JaCoCo的引入，可方便的定位到存在問題的代碼行及單元測試情況。

圖4.問題定位

自動化測試流水線

持續交付講究Automate almost everything將一切過程自動化起來，減少人工的幹預。這裏我們主要加入了以下環節。

自動化的接口及集成測試

測試進入的越早，發現問題修復的成本越低，通過引入TestNG等測試框架，對接口以及模塊集成進行測試，有效的降低Bug流入後續環節的風險。

測試分級

將測試用例拆分成SmokingTest、AllTest等多套用例集，一方面快速反饋代碼更新可能引起的風險，同時保證測試的有效覆蓋，同時通過分布式集群並發執行等方式，加速執行效率，最終形成以下的流水線。

圖5.管道流水線

自動化交付及全平臺工具整合

在傳統模式下開發、測試、運維往往比較獨立，測試完成後由運維人員進行部署上線，但是由於運維人員能力水平存在高低，復雜環境下的發布往往只有固定的幾人才能搞得定，從而導致上線發布周期被拉長。我們通過自建交付自動化工具，同時整合平臺讓運維對外提供服務，消除開發、測試與運維之間的邊界，大大降低了自動化運維的門檻，讓運維效率有了很大的提升。

圖6.交付自動化

通過作業流程的編排，沈澱標準化作業封裝，讓普通運維人員快速實現相應的自動化腳本，同時通過整合資源/環境，對開發測試提供資源申請、部署等服務，加速自動化發布的驗證，避免在正式發布時導致問題。

持續的反饋

上線發布完成並不意味著交付結束，當今社會是一個以服務取勝的社會，我們交付給用戶的不再是簡單的產品，更多的應該是服務。通過自動化的監控獲取用戶的反饋快速做出響應，不斷提升我們的服務，才能提高用戶的滿意度和粘性。

總結

持續交付是一套方法論，通用的並不一定適合自己。希望僅以本文做一個引子，讓大家尋找到適合自身的持續交付之路！附上一張交付過程中的工具集供大家參考。

作者介紹

葛成遠，10年測試老兵，掉入運維領域而無法自拔。

本文出自 “優雲雙態運維” 博客，請務必保留此出處http://uyun2017.blog.51cto.com/12912719/1926643

交付自動化的探索與展望