持續集成、持續交付、持續部署

持續集成、持續交付、持續部署

三豐 soft張三丰
「最後一哩」問題
　　持續集成解決了軟件開發中的部分問題，但還有更爲重要的一部分有待解決，即「經過什麼樣的方法，可讓軟件儘快地在真正的生產環境下運行，從而實現軟件的價值」。在軟件開發過程當中，「從功能開發完成開始直到將其部署至生產環境中正式運行」這一階段被稱爲「最後一哩」。若是從一開始就對產品發佈足夠重視的話，那麼這「最後一哩」可能只須要幾分鐘，甚至幾秒鐘就完成了。然而，事實上大多數項目在這一階段會花上幾個星期，更有甚者可能會是幾個月。
　　爲何會這樣呢？對於複雜軟件來講，不管什麼環境中的部署（測試環境，試運行環境，仍是生產）都很困難。當軟件第一次被部署到非開發環境去測試，或者當軟件功能及其環境有較大變化時，一般都會暴露出不少問題。而在作用戶驗收測試時，經常會發現更多的問題，例如不能知足非功能需求，用戶操做不方便，功能與用 戶真正須要的東西相差太遠等等。而開發團隊只有修復這些缺陷後，才能再次部署測試。因而，這個過程會不斷反覆，直至該軟件足夠穩定，才能夠部署到生產環境中。
　　即然部署到測試環境都這麼困難，那麼在生產環境中部署的風險豈不會更大嗎？並且，更爲嚴重的是：當生產環境部署出現問題時，擺在你面前的選擇就所剩無幾啦（一般是回滾到之前的狀態，而「回滾」這段時間的停機成本是至關高的）。
上述緣由就會致使大多數組織對產品的發佈採用「保守策略」，即下降軟件的發佈頻率，這也致使兩次發佈之間的版本特性差別相對較大。這樣一來，發佈風險並未因發佈間隔時間加長而下降，反而更高了。當各方面的因素結合在一塊兒時，軟件發佈這一環節就變得昂貴而又緩慢啦。而一般「發佈過程與頻率」決定了產品在市場中的位置。
　　那麼，如何更好地解決「最後一哩」這一問題呢？實現持續部署！即將持續集成實踐擴展到整個軟件生命週期頻繁且規律性地自動構建代碼並將其部署到測試環境中，而後經過一系列的測試，選擇適當的版本部署到預演環境中試運行，最後選擇穩定的版本部署到生產環境中，從而使開發團隊儘早從最終客戶那裏獲得反饋，而最終客戶儘早獲得軟件的價值。

墨菲定律你們都不陌生，越是擔憂什麼就越會發生什麼；在多團隊協做時，好比系統對接時，咱們都會擔憂對接是否順利，每每也不枉咱們擔憂，時常咱們會被集成折磨得焦頭爛額。有不少團隊只是擔憂，並無拿出有效的措施去避免這種事情發生，以致於延長了交付時間。既然擔憂，咱們何不及早集成，把問題先暴露出來？

目前多數公司都已經使用了版本管理工具來管理源碼，好比GitLab、SVN 等版本管理工具。在版本管理這一塊，公司會根據本身的實際狀況來制訂版本管理辦法。對於持續集成來講，業內建議只維護一個源碼倉庫，下降版本管理的複雜度。開發人員持續提交本身的修改，自動觸發編譯，自動集成，自動進行自動化的測試，及早反饋集成過程當中的問題，就能更好地防止出現平時不集成、集成就出問題的現象。

經過自動化的持續集成，把管理流程固化；保證集成的有序性、可靠性；減小版本發佈的不合規性（開發或者測試手動打包，可能一天打多個包，更新屢次，測試不充分），保證版本可控，問題可追溯（至於哪一個版本出現的問題，能夠回溯）。

一旦把這種持續集成的過程固定下來，造成一個自動化過程，就具有了持續集成的能力，軟件交付的可靠性就大大加強，這無形也是一種競爭力。這種競爭力保證了集成的有序性、可靠性。過程的自動化拋棄了人工，下降了出錯率，提升了速度，天然會節省成本。

對於大規模的CI&CD，一旦系統數量、實例數量上去後各類問題就都來了。下面列舉幾個主要的問題。

1）更新問題。更新一次要耗費大量精力，不少企業都是晚上更新，員工得通宵加班，還不能保證更新沒問題，不具有快速大批量部署的能力。

2）部署包（jar 包、war 包、ear 包等）的管理問題。爲了保證版本可追溯，出錯後可以回滾，咱們須要保存各個歷史版本，並且方便下載。

3）版本的安全性。傳統上以Java 語言開發的系統多數以jar 包、war 包、ear 包的方式發佈，容易被篡改（人爲修改，傳輸過程不完整）；一般咱們用md5 來驗證完整性，但包與md5 對應關係的管理並無系統化，每每在出問題後人工進行md5 驗證。

4）主機管理問題。系統部署到哪些機器上須要進行主機管理？在部署時人工選擇部署到哪臺主機顯然不是一種明智的方式，可否自動進行調度？同時，不會產生有些主機性能堪憂、有些主機空閒致使的負載不均狀況。

5）端口管理問題，在部署Java 項目時咱們並不建議設置太多的JVM 內存，所以一臺主機上每每可以部署多個應用實例，同一臺機器上多個實例的開放端口就必須不一致，因而端口又成了須要管理的資源。有人會說能夠選用虛擬機，一臺虛擬機上只部署一個實例。固然，這也是能夠的。實際上，多數企業也是這麼作的。這種作法也有弊端，虛擬機雖然幫助作了隔離，但會損失一些主機性能；虛擬機要使用內網IP，這樣IP 又成了稀有資源，當部署多個實例時IP 會不夠用。

6）負載均衡管理問題。不論是在主機上部署多個實例，仍是利用虛擬機來部署多個實例，在作集羣時，都會經過代理（Nginx、Apache、LVS……）軟件來作負載均衡，所以咱們須要把各實例的訪問地址配置到負載器的配置文件中。實例數少的時候手工配置還能夠接受，多了就無法手工配置了。固然，方法也會有，好比用Etcd+Confd+Nginx（HAProxy）來作服務發現，咱們須要本身部署一套工具，並進行維護，複雜的框架提升了對運維人員的要求。

7）服務伸縮問題。當服務訪問量上去後，要可以具有快速擴充的能力；當訪問量下去後，要可以具有縮小服務規模的能力，收放自如。這種彈性的服務能力顯然是經過工具來完成的，手動完成是不可能的。

8）IP 管理問題。當大規模部署後，IP 資源會成爲稀有資源，如何用更少的IP 來部署更多的服務？IP 的分配及管理顯然不能人工完成，那樣效率太太低下，這就須要一個IP 管理工具。

DevOps靜態架構

CI&CD 流程

持續集成 的含義爲：頻繁的（一天屢次的）將全部開發者的工做合併到主幹上。
以圖例說明持續集成的流程：

從圖例上來看持續集成的流程就十分清晰了：

• 開發人員提交代碼到 Source Repository （源代碼倉庫），並經過 git hook 等
• 觸發 CI Server（持續集成服務器）的相關功能。執行 編譯 -> 測試 -> 輸出結果 的流程，
• 向開發人員反饋結果的 report
  能夠看出，持續集成的 核心 在於 確保新增的代碼可以與原先代碼正確的集成。與後續要介紹的持續交付以及持續部署，其最主要的差異也就在於其目標不一樣。

  持續集成的優點

和咱們一直在使用的 階段集成（完成一個階段的開發後執行代碼的集成） 相比， 持續集成 的策略可以爲咱們帶來哪些好處呢？

• 易於定位錯誤：每一次的代碼集成都須要執行相關的測試工做，持續集成頻繁的集成次數自然的將複雜的代碼邏輯切割爲了小塊，也就使得每一次測試中遇到的錯誤可以更加容易的被定位；
• 易於控制開發流程：更爲細緻的工做提交也就意味着更容易判斷當前的工做進度，這對於管理者規劃開發流程而言提供了一個有效的參考，同時也爲開發人員省下了彙報工做的時間；
• 易於CodeReview：對於大塊工做的切分天然也有助於作 CodeReview；
• 易於減小沒必要要的工做：build 以及 test 過程的自動化能夠爲你節約一大票的時間，從而投入到有價值的工做中去。
  在傳統的團隊組織方式中，開發人員與運維人員之間是割裂開的，軟件開發流程被分割爲多個獨立環節，分別由不一樣的人員執行。這使得軟件開發過程當中須要付出高昂的溝通成本，層層手動的流程將大量的時間耗費在了重複的勞動中。在 DevOps 的指導下，不一樣技能的人員處在同個團隊中，爲了一個共同的軟件開發目標而工做，更好的協同工做與自動化的手段可以優化整個 Code -> Build -> Test -> Release -> Operate -> Code 的循環。這一理念看起來很美，用圖畫來講明就構成了一個和諧友好的大圈，不過在實際應用中也許會遇到很多問題，例如不一樣技能人員之間相互溝通的額外開銷、團隊組織形式改變後爲管理所帶來的困難等等。這些問題大概等到真正將 DevOps 在開發過程當中開展來才能作解答了。