為什麼要持續集成與持續部署
DevOps、持續集成、持續交付、持續部署、敏捷等詞語大家應該都耳熟能詳了，說到底就是快速交付價值，從工程上、管理上、組織上、工具上來提高效率，打造可靠的、快速的產品（項目）交付過程。本書將圍繞項目管理、自動化部署、自動化發布、自動化測試、容器雲來實現持續集成、持續交付及持續部署，因為它不是一本理論圖書，不打算大談道理，我們將直接談論持續集成、持續交付、持續部署的價值，拋出問題，說思路，講方案，講實際操作。希望能夠幫助廣大讀者快速在企業落地持續集成、持續交付與持續部署。
1.1CI&CD 的價值
持續集成（Continuous Integration，CI）是一種軟體開發實踐。在持續集成中，團隊成員頻繁集成他們的工作成果，一般每人每天至少集成一次，也可以多次。每次集成會經過自動構建（包括靜態掃描、安全掃描、自動測試等過程）的檢驗，以儘快發現集成錯誤。許多團隊發現這種方法可以顯著減少集成引起的問題，並可以加快團隊合作軟體開發的速度（以上引用自Martin Fowler 對持續集成的定義）。
持續交付（Continuous Delivery）是指頻繁地將軟體的新版本交付給質量團隊或者用戶，以供評審，如果評審通過，代碼就進入生產階段。
持續部署（Continuous Deployment）是持續交付的下一步，指的是代碼通過評審以後，自動部署到生產環境中。
通過上面的定義我們不難發現，持續突出的就是一個快字，商業軟體的快速落地需求推動了軟體工程的發展。可持續的、快速迭代的軟體過程是當今主流開發規約。尤其在互聯網行業，快速響應即是生命線。從一個想法到產品落地都處在衝鋒的過程中，機會稍縱即逝。響應用戶反饋也是萬分敏捷，早晨的反饋在當天就會上線發布，快得讓用戶感覺倍受重視。「快」已經成為商業競爭力。這一切都要求企業具備快速響應的能力，這正是推動持續集成、持續交付、持續部署的動力。
產品或者項目的參與者應該能夠深刻體會到團隊協作時，工作交接（系統集成）部分最容易出問題，會消耗大量的溝通成本與時間成本，直接拖慢進度。所以，一個行之有效的項目管理過程（包括溝通管理、流程管理）在大型項目中效果明顯。當前敏捷開發是主流，持續集成、持續交付與持續部署正好能夠幫助高效地實施敏捷過程，促進開發、運維和質量保障（QA）部門之間的溝通、協作與整合。
1.2 CI&CD 帶來的變化
通常把開發工作過程分為編碼、構建、集成、測試、交付、部署幾個階段（見圖1-1），持續集成、持續交付、持續部署剛好覆蓋這些階段。從提高效率上來講，對每個階段的優化都可以縮短軟體交付時間。持續集成、持續交付及持續部署的過程即是一個軟體開發優化過程。
墨菲定律大家都不陌生，越是擔心什麼就越會發生什麼；在多團隊協作時，比如系統對接時，我們都會擔心對接是否順利，往往也不枉我們擔心，時常我們會被集成折磨得焦頭爛額。有很多團隊只是擔心，並沒有拿出有效的措施去避免這種事情發生，以至於延長了交付時間。既然擔心，我們何不及早集成，把問題先暴露出來？
目前多數公司都已經使用了版本管理工具來管理源碼，比如GitLab、SVN 等版本管理工具。在版本管理這一塊，公司會根據自己的實際情況來制訂版本管理辦法。對於持續集成來說，業內建議只維護一個源碼倉庫，降低版本管理的複雜度。開發人員持續提交自己的修改，自動觸發編譯，自動集成，自動進行自動化的測試，及早反饋集成過程中的問題，就能更好地防止出現平時不集成、集成就出問題的現象。
通過自動化的持續集成，把管理流程固化；保證集成的有序性、可靠性；減少版本發布的不合規性（開發或者測試手動打包，可能一天打多個包，更新多次，測試不充分），保證版本可控，問題可追溯（至於哪個版本出現的問題，可以回溯）。
一旦把這種持續集成的過程固定下來，形成一個自動化過程，就具備了持續集成的能力，軟體交付的可靠性就大大增強，這無形也是一種競爭力。這種競爭力保證了集成的有序性、可靠性。過程的自動化拋棄了人工，降低了出錯率，提高了速度，自然會節省成本。
1.3 CI&CD 實施現狀
在日常生活中處處都體現著一個「快」字，互聯網更是對快追求到極致。持續集成、持續交付、持續部署在互聯網行業更為廣泛。作者沒有統計哪些公司在用，只是圈子中朋友公司都實施了持續集成，具備持續交付能力。至於持續部署就沒這麼廣泛了，畢竟持續部署不僅僅是技術問題，還涉及管理、營運等問題。尤其是一些金融企業、大型國企，開發團隊外包，測試外包，運營半外包，安全要求高，很難快速實施。多數能夠在測試環境中建立起CI&CD就已經很不錯了。
阿里雲、騰訊雲、網易蜂巢等國內雲，都提供了從GitLab 下拉代碼、編譯打包、單元測試、鏡像製作、容器發布的功能。這個過程實際上就是持續集成、持續交付的過程，同時具有持續部署的能力。基本上，持續集成、持續交付、持續部署是一種服務能力，是雲平台必須具備的能力。
下面引自2017 年DevOps 現狀調查報告。
統計資料顯示，DevOps 正在各個行業、各種規模的企業中落地。DevOps 團隊的比例在2014 年是16%，在2015 年是19%，在2016 年是22%，在2017 年已經增長到27%，越來越多的企業和團隊開始擁抱DevOps。圖1-2 是2017 年DevOps 現狀調查報告統計的從業分布情況。
完整的報告可以從qcloudimg 網站下載。
在本書撰寫過程中2018 年DevOps 現狀調查報告也已經出來，圖1-3 是精英級執行團隊使用DevOps 後的效率。精英級執行團隊在以下幾個方面有著突出的表現。
1）代碼發布頻率高46 倍。
2）代碼從提交至發布的速度快2555 倍。
3）故障變更率降低1/7。
4）事故恢復時間快2604 倍。
另外，雲計算持續增長（見圖1-4）。有17%的調查者仍然沒有使用雲廠商的服務。AWS最受歡迎，佔比為52%，Azure 屈居次席，佔比為34%。
1.4 CI&CD 技術棧
目前持續集成、持續交付、持續部署在開源社區都是熱點，用戶可以方便地利用這些開源組件來構建自己企業的持續集成、持續交付及持續部署平台。
持續集成工具中以Jenkins 使用最為廣泛，由Jenkins 來作業化持續集成過程；利用GitLab來管理程序版本；利用Gerrit 來做代碼審核；利用Sonar 進行代碼質量掃描；利用JUnit 進行單元測試；利用Docker compose 來構建鏡像；利用Docker 來部署容器；利用Kubernetes、Rancher 等進行服務編排。圖1-5 顯示了常見的CI&CD 技術棧。
後續講解CI&CD 落地時會運用到其中的一些技術與工具。當然，基本上都運用開源工具，這也有助於企業在落地時節省費用。
1.5 大規模部署的煩惱
對於同樣的功能，在用戶量不同的系統中，工作量是完全不同的，後台為性能考慮而設計的架構完全不一樣。對於CI&CD 也是如此，小規模的很容易，配幾個作業就可以完成工作，但對於大規模的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 管理工具。
如果有一個系統能夠一站式解決以上問題，那真是太完美了。因為沒有這樣的系統，所以很多公司開發了他們的運維平台，專門用來解決大規模部署問題。但對於中小公司來說，技術與人力投入往往受限，沒有這個能力、精力或者財力去建立一個智能的運維平台。但是我們可以利用開源工具、開源技術來搭建一個相對完善的持續集成、持續部署體系。
1.6 實施雲平台化
虛擬化、雲平台化為大規模部署提供了方便，尤其是在硬體資源管理及網路管理方面。互聯網的火熱更是推動了雲的快速發展，基本上各大互聯網企業都已經完成了雲平台化，生產力也在不斷提升。以Docker 為代表的容器化技術出現後，雲變得更靈活，容器化已經成為大潮，Docker 也佔據了容器市場的絕對份額。容器部署方式能夠滿足快速大批量部署的要求，充分利用物理機器資源。以Docker 為例，Docker 容器技術讓應用一次構建，到處（物理機、虛擬機、公有雲、私有雲、Windows 系統、Linux 系統等）可運行，加快了本地開發和構建，實現了快速交付和部署；同時還可以在操作系統層面提供資源隔離服務。
為了提高服務水平，企業服務需要能夠快速水平擴展，在系統設計層面也大舉採用SOA框架，這種框架天生適合使用容器大規模部署。當然，也存在一些問題，比如管理大量的服務實例成為一個挑戰，運維、監控、問題分析等變得複雜。那麼如何管理這些容器呢？於是就產生了大量的容器管理工具，支持Docker 容器管理的工具使用得比較廣的有Swarm、Mesos、Kubernetes、Rancher 等工具。這些工具能夠幫我們方便管理容器，雖然有一些問題的解決方式並不完美，但這也給運維開發、測試開發提供了更多的想像空間與工作機會。目前容器管理工具Kubernetes 影響最大，但Kubernetes 的學習與運維成本相對較高，需要專業人士的支持。目前國內大型互聯網公司基本都基於Kubernetes 來管理大量容器，包括BAT、京東等企業。騰訊的藍鯨（DevOps）也基於Kubernetes，已經開始市場化；淘寶的雲效也是與藍鯨同類型的產品。
對於中小型企業來說，上Kubernetes 顯得有點操之過急，需要有技術儲備與維護團隊，學習成本相對也會高一點，因此應該選擇簡單的、快速能夠落地的、能夠滿足企業要求的、有一定市場的工具。當然，最好還是開源的，社區也支持的。所以我們選擇Rancher，據說早期雲效也是整合Rancher 的，作者也在基於Rancher 做整合，利用Rancher 實現容器的管理，利用Jenkins 構建，利用GitLab 實現源碼管理，再加上靜態掃描、自動化測試、性能測試、日誌管理等功能，整合成DevOps，足夠運行、管理上千個實例級別的容器實例。實際上，擁有DevOps 並且已經容器化，就相當於已經擁有一個相對智能化的私有雲平台（不是真正意義上的雲，並沒有對物理資源進行管理，抽象成服務）。圖1-6 是作者早期開發的DevOps靜態架構。
此平台類似於一個私有雲平台，基本涵蓋了系統的生命周期：編譯、打包、發布、測試、上線、運維、下線。同時把硬體資源管理起來，這些硬體對用戶透明。平台主要分3 層。
? 基礎組件層，提供了存儲、網路與運算功能。對於上層來說，硬體只是一個服務而已。
? 服務組件層，提供了運維與監控功能。對於大規模系統營運來說，系統監控、問題診斷分析變得複雜，必須在系統層面給予幫助，結合平台能力，讓用戶分析問題變得簡單。那種從伺服器上看日誌的老舊方式一去不復返了。
? DevOps 用戶層，直接面向運維人員，做到持續集成、持續交付、持續部署，在平台中完成各種測試。支持多種形式的發布，減少上線風險。
圖1-7 是上述平台用到的技術棧。下面對用到的部分工具進行簡單說明。
? Rancher：一個開源的企業級容器管理平台。通過Rancher，企業再也不必自己使用一系列的開源軟體去從頭搭建容器服務平台。Rancher 提供了在生產環境中使用的管理Docker 和Kubernetes 的全棧化容器部署與管理平台。
? Jenkins：用於構建管理，定義管理工作過程。
? Docker compose：一種定義編排容器的工具，以YAML 或者XML 的格式展示編排內容。
? Maven：源碼編譯工具。
? GitLab：源碼管理工具。
? Gerrit：代碼審核工具。
? Sonar：代碼靜態掃描工具。
? robot：自動化測試工具。
? Ceph：分散式存儲產品。
? Spring Boot：DevOps 集成開發技術框架。
? React：門戶開發框架。
? Redux：門戶開發框架。
? MySQL：資料庫。
? MyBatis：ORM 框架。
? Kibana、Logstash、Elastic：用於統一進行日誌管理、日誌存儲、日誌分析。
本書講到的CI&CD剛好是這個DevOps 的一個子集，我們將圍繞上述架構及技術棧展開，
本書不僅講解如何實現，還會結合實例展示如何落地。這些對於大多數中小型企業來說已經足夠支撐業務。企業給CI&CD 加上Web 版本的門戶、集中的賬戶管理體系以及運維監控體系，即可打造一個智能的DevOps 平台。
圖1-8 是CI&CD 流程，後面的實例也將圍繞這個流程。
下面先簡單介紹該流程。
1）程序員提交代碼。
2）Gerrit 做代碼審核，通過提交到GitLab，能通過郵件通知相關人員。
3）Sonar 做代碼靜態掃描，並把結果通知相關人員。
4）在GitLab 中貼標籤（通過WebHook 觸發Jenkins 作業）或者手動在Jenkins 中觸發作業，Maven 開始下拉代碼進行編譯，然後進行單元測試和打包。
5）打包完成後利用Docker cli 構建鏡像。
6）把鏡像上傳到鏡像倉庫中。
7）Jenkins 作業觸發Rancher 在測試環境中啟動容器，首先下拉鏡像，然後根據配置啟動容器。
8）Rancher 自動或者按規則調度容器在哪台機器上運行。
9）Rancher 負責容器生命周期管理（啟動、監控、健康檢查、擴展等）。
10）進行自動化測試。
11）測試通過後，Jenkins 觸發Rancher 在生產環境中啟動或者更新測試通過的服務，當然，也可以手動在Rancher 中進行發布，當實例增加時只需要填寫實例數量即可快速擴展，在發布時可以支持灰度發布、藍綠髮布等個性化的發布需求。
注意：
1）我們一直不加上雲平台這個名稱，是因為雲平台的定義太廣，我們並沒有產品接入功能，比如提供數據存儲服務、緩存服務，以及提供大數據運算能力。
2）當然，我們也具備雲要提供的很多服務，所以在把下面要講的一套東西落地後，也可以冠以雲平台之名，其他的功能可以慢慢補上來。「欲立新功，行之有名；立人之先，憨享其成。」
由於要用的工具比較多，這些工具多由外國人開發，譯過來叫法比較多，因此為了方便講述，下面介紹術語。
? 服務：完成某一功能的程序。
? 服務實例：程序部署單元，比如一個訂單程序由Tomcat 啟動，一個這樣的部署單元（一個JVM 實例）稱為一個服務實例。
? 容器：如Docker 容器。
? 容器實例：鏡像的運行態叫容器實例，如果運行一個Nginx 鏡像，那麼這就是一個容器實例，我們利用鏡像運行兩個Nginx，那麼實例數為2；這些實例稱為容器實例，一定語境下直接稱為實例。
1.7 本章小結
本章簡單敘述了進行CI&CD 的價值，以及通過CI&CD 的實施能夠幫我們解決什麼問題。結合當前的CI&CD 技術棧，我們知道要朝哪個方向去發力建立自己的私有雲平台。利用當前的開源技術實現CI&CD，運行自己的私有雲平台，加速企業的系統集成效率，縮短部署時間，提高成功率。
本文摘自《持續集成與持續部署實踐》
《持續集成與持續部署實踐》
作者：陳志勇 錢琪 孫金飛 李誠誠
《持續集成與持續部署實踐》(陳志勇，錢琪，孫金飛，李誠誠)【摘要 書評 試讀】- 京東圖書
- 騰訊、阿里、滴滴等公司眾多專家推薦
- 講述如何用Docker構建集成容器、鏡像倉庫規劃及管理
- 一書在手，持續集成無憂。
本書來自一線的實踐經驗，深入呈現技術細節；詳實的實操示例，即學即用的實戰技術。
講解了持續集成中引人入勝的內容：CI/CD到底要解決什麼問題？它與DevOps之間的關係是怎樣的？程序員如何用工具化的系統持續進行代碼的版本管理、構建、打包、集成、測試和部署？利用雲平台和容器技術實現彈性伸縮價值等。
推薦閱讀：
