想搞懂持續交付理論和實踐，你只差這三個問題
摘要：今天，我們來了解下什麼是「持續交付」及「持續交付」的實踐。
雲原生是當下IT圈非常熱門的一個詞，其目的是為了各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生包含很多技術，比如容器、微服務、DevOps、持續交付等，今天，我們來了解下什麼是「持續交付」及「持續交付」的實踐。
什麼是持續交付
持續交付是指，所有開發人員都在主幹上進行小批量工作，或者在短時間存在的特性分支上工作且定期向主幹合併，同時始終讓主幹保持可發布狀態，保證程式碼可以按需進行一鍵式發布。開發人員在引入任何回歸錯誤時（包括缺陷、性能問題、安全問題、可用性問題等），都能快速得到回饋。一旦發現這類問題，就立即加以解決，從而保持主幹始終處於可部署狀態。
( Wikipedia: Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. )
持續交付是持續集成的延伸，將集成後的程式碼部署到類生產環境，確保可以以可持續的方式快速向客戶發布新的更改。如果程式碼沒有問題，可以繼續手動部署到生產環境中。
持續交付流水線
隨著開發模式的日益成熟，軟體開發過程中的每個環節已經越來越標準化了，但是這些環節都相對獨立，需要一個東西將他們連接成一個整體。
如果我們能將這些環節——構建、發布、測試、部署有效的串聯起來，形成一套完成的持續交付流水線，就能提高軟體的發布效率與品質，持續不斷的創造業務價值。
持續交付流水線工作流程大致如下：
- 開發人員將程式碼提交至程式碼倉庫；
- 編譯構建伺服器獲取到程式碼倉庫文件變更資訊，從程式碼倉庫拉取程式碼，進行編譯構建，生成二進位軟體包，並將生成的軟體包保存到製品庫。構建過程中，每一步成功與否，都需將結果回饋給對應的開發人員。
- 構建完成後，將軟體包按需部署到測試環境，進行測試，同時測試結果回饋給開發人員，
- 測試完成，由業務側決定是否將軟體包發布到生產環境，如果需要發布，則通過人工將軟體包發布到生產環境。
當然，流程並非固定的，可以根據具體的業務需要，穿插其他流程，比如靜態程式碼檢查，性能測試等。
為什麼要做持續交付
持續交付適用於幾乎任何對品質、交付速度和結果的可預測性有要求的低風險部署和發布場景，包括嵌入式系統、web應用、移動應用等。開發者通過持續交付可以自動完成發布過程，並且可以通過單擊按鈕隨時部署應用程式。
理論上講，持續交付可以滿足每日一次、每周一次等固定發布頻率，或者滿足業務需求的任何頻率，但是，如果真的想獲得持續交付的好處，應儘早將應用部署到生產環境，以確保可以小批次發布，並且發現問題後及時排除故障。
實踐：通過華為雲DevCloud實現持續交付
程式碼提交
華為雲DevCould程式碼託管CodeHub是一個線上程式碼倉庫，為開發者提供基於Git的在線程式碼託管服務，包括程式碼克隆/提交/推送/比較/合併/Code Review等功能。
開發人員可將程式碼提交至CodeHub。
編譯構建
在「編譯構建」服務中，用戶可根據自己的程式語言，編程環境，自主配置所需的構建步驟，並對指定的程式碼倉庫進行編譯構建。
當然華為雲DevCloud的編譯構建功能支援持續集成：提交程式碼觸發執行編譯構建。
配置部署任務
部署功能與編譯構建在使用方面類似，都是根據自己的業務場景配置相應的部署任務，任務配置完成後，可根據業務需要，執行部署任務。
持續交付流水線
之前提到了持續交付流水線，華為雲DevCloud流水線功能可以將已經配置好構建，部署等服務串聯到一起，實現一鍵部署。
