一 《持續交付》

書籍推薦

1 手工部署軟件 模式

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

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

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

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

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

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

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

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

相反,隨著時間的推移,部署應該走向完全自動化,即對於那些負責將應用程序部署到開發環境、測試環境或生產環境的人來說,應該只需要做兩件事:

(1)挑選版本及需要部署的環境,(2)按一下“部署”按鈕

二 什麽是持續交付和持續部署？

維基百科定義：

續交付（Continuous delivery，縮寫為 CD），是一種軟件工程方法，讓軟件產品的產出過程在一個短周期內完成，以保證軟件可以穩定、持續的保持在隨時可以發布的狀況。它的目標在於讓軟件的編譯、測試與發布變得更快更頻繁。這種方式可以減少軟件開發的成本與時間，減少風險。

持續交付所描述的軟件開發，是從原始需求識別到 最終產品部署到生產環境這個過程中，需求以小批量形式在團隊的各個角色間順 暢流動，能夠以較短地周期完成需求的小粒度頻繁交付。頻繁的交付周期帶來了 更迅速的對軟件的反饋，並且在這個過程中，需求分析、產品的用戶體驗和交互 設計、開發、測試、運維等角色密切協作，相比於傳統的瀑布式軟件團隊，更少 浪費。

理想場景：

有一天，業務人員急沖沖的跑過來，對你說生產上出現了一個嚴重 BUG，必須要盡快修復。你聽完問題描述後，胸有成竹坐定並迅速定位問題，隨後改動了一行代碼並提交，系統開始自動編譯、各個環境自動化測試、發布上線。幾分鐘後，生產環境上該 BUG 已經被修復掉。

概念澄清：

活動圖描述：

持續交付歸納出四個關鍵要素：持續集成、自動化測試、自動化部署、流水線。

隨想之六-持續部署