DevOps是當前炒的很火熱的概念，實踐DevOps的方法涉及兩個方面，一是如何持續管理需求、變更和及時處理用戶反饋，通過工具固化一定的流程，有效的管理需求和變更。另一方面就是如何持續交付。
作為DevOps流程的核心實踐持續交付(Continuous Delivery)在這其中能夠為軟件項目帶來什么價值呢？本文將結合持續交付的具體實踐展開分析與討論。
入手持續交付
持續交付最基本的原則是：
提前并頻繁地內部交付，將幾乎所有事情自動化
持續交付最核心的實踐是自動化，通過將每一次改動都提交到一個模擬產品環境中，使用嚴格 的自動化測試，確保業務應用和服務能符合預期，使用完全的自動化過程來把每個變更自動的提交到測試環境。
實現自動化的持續交付基于部署流水線模式。
部署流水線的目的是讓軟件交付過程中的每個人都能看到每個構建版本從提交到發布的整個過程，將開發機構的文化、流程和工具整合到一起，這也符合了DevOps的核心理念將開發機構的文化、流程和工具整合到一起。
下面討論部署流水線的細節。
腳本化構建與部署
腳本化構建與部署應以迭代的方式來識別最困難的步驟，并將其自動化，沿著部署流水線，逐步完善自動化構建和部署能力。腳本化構建與部署應該遵循如下原則：
- 為部署流水線的每個階段創建腳本，表達構建流程。
- 使用同樣的腳本向所有環境部署，保證在所有環境上都能運行。
- 確保部署過程是冪等的。
- 增量式部署。
提交
提交階段發生在像版本控制庫提交代碼，是流水線的入口。提交階段應遵循如下原則：
- Dev保證本地構建成功后提交
- 測試不通過令提交失敗，并記錄錯誤信息，反饋Dev盡快修復，Dev對自己的問題負責
- 提交失敗后可以回滾版本
- 降低構造測試環境的復雜性，保證測試代碼整潔有效性。
自動化驗收測試
單元測試不能保證捕獲所有問題，因此需要驗收測試來保證軟件質量。頻繁的手工測試帶來高昂成本，采用自動化驗收測試便于頻繁發布軟件。
自動化驗收測試使得團隊成員都關注于真正的工作：業務價值，為軟件能否滿足標準提供了更高得信心，快速向開發團隊反饋問題，便于軟件大規模重構。
非功能性需求測試
非功能需求測試包括容量、吞吐量以及性能測試。
將非功能性需求加入到部署流水線上，便于軟件設計執行實驗場景來幫助診斷預測問題。
對于非功能需求，過早地關注容量優化是低效且昂貴的，有可能造成過度設計，除非性能有問題，不在代碼可讀性上讓步。
發布
頻繁地將軟件發布到不同的測試環境中，能夠降低發布的風險，降低上線壓力。
發布過程將組織各部門聯系起來：運維團隊，開發團隊，測試團隊，技術支持團隊，交付團隊，促進交流合作。
持續交付對于運維的改變
DevOps將敏捷方法引入到系統管理與運營，有兩點主要原則：
- 強調合作
- 利用敏捷技術對基礎設施進行有效管理
運維負責將代碼部署到生成環境中，持續交付從一開始就讓運維參與進來，兩者共同的利益是
讓發布有價值、穩定得軟件成為一件低風險的事
持續交付的核心實踐 盡可能頻繁的發布 保證了這一點，從而成為了DevOps的關鍵步驟。
自動化環境管理
對于運維人員的工作，關鍵的痛點在于部署系統到不同配置的大量基礎設施上，對基礎設置的管理往往利用腳本管理，修改基礎設施的技術也應該是發布的一部分。
將基礎設施的配置自動化，納入流水線并配置測試會大大便于運維的部署管理工作。
另一種方案，使用docker進行持續集成
在業務不斷增長過程中，企業的組件也隨之不斷擴張，隨之帶來了對基礎設施的復雜配置管理工作。采用自動化部署配置管理無疑產生巨大成本，使用Docker——以“容器化”的方式去部署應用。 Docker像集裝箱一樣，打包了所有依賴，再在其他服務器上部署很容易，不至于換服務器后發現各種配置文件散落一地，這樣就解決了編譯時依賴和運行時依賴的問題。
利用Docker進行持續集成的流程如下：
- 開發者提交代碼；
- 觸發鏡像構建；
- 構建鏡像上傳至私有倉庫；
- 鏡像下載至執行機器；
- 鏡像運行。
價值
貫穿持續交付始終的是自動化手段，這也恰恰是軟件行業所追求的，自動化的交付過程帶來了諸多益處：
- 快速發現錯誤。每完成一點更新，就集成到主干，可以快速發現錯誤，定位錯誤也比較容易。
- 快速發布。能夠應對業務需求，并更快地實現軟件價值。
- 編碼->測試->上線->交付的頻繁迭代周期縮短，同時獲得迅速反饋；
- 高質量的軟件發布標準。整個交付過程標準化、可重復、可靠，
- 整個交付過程進度可視化，方便團隊人員了解項目成熟度；
- 更先進的團隊協作方式。從需求分析、產品的用戶體驗到交互 設計、開發、測試、運維等角色密切協作，相比于傳統的瀑布式軟件團隊，更少浪費。
- 更平滑的開發過程，減少上線風險，增強團隊信心。
