關(guān)于DevOps CI/CD Pipeline，看這篇就夠了 | IDCF
來源：CIO Talk 作者：馬景賀
提到DevOps，很多人就想到了CI/CD Pipeline，甚至很多個人或者企業(yè)認(rèn)為完成了CI/CD Pipeline就等于實現(xiàn)了DevOps，雖然這種觀點有失偏頗，但是從側(cè)面反映了CI/CD Pipeline在DevOps中扮演著舉足輕重的地位。CI/CD 是DevOps 的兩大關(guān)鍵核心能力。CI/CD Pipeline的真正實現(xiàn)會加速企業(yè)向DevOps轉(zhuǎn)型的進(jìn)程。本文將揭開CI/CD Pipeline的神秘面紗，來一探究竟。
一、什么是 CI/CD Pipeline
Pipeline 指管道或者流水線，類似于工廠里的生產(chǎn)線，原料從一端輸入，中間經(jīng)過多個工作中心，一個工作中心的輸出作為下一個工作中心的輸入，最終在另一端輸出高質(zhì)量的產(chǎn)品。CI/CD Pipeline 指CI/CD的流水線，在輸入端輸入源碼，經(jīng)過既定工作流，最后在輸出端輸出對用戶有價值的產(chǎn)品。從字面就能看出側(cè)重點持續(xù)、流水線。
CI/CD Pipeline的簡單示意圖如下。
開發(fā)人員提交完代碼，經(jīng)過一系列的流程，最后生產(chǎn)出有價值的應(yīng)用程序。
二、為什么需要 CI/CD Pipeline
DevOps的出現(xiàn)就是為了解決實際問題：打破橫亙于開發(fā)人員與運維人員之間的壁壘。CI/CD Pipeline 可以幫助實現(xiàn)這個目的：開發(fā)人員在代碼提交之后，就有CI/CD 流程來對所開發(fā)代碼的功能性，健壯性，安全性等進(jìn)行驗證，如果驗證失敗，就返回至開發(fā)人員處，繼續(xù)修改；如果通過既定流程，就可以進(jìn)行生產(chǎn)部署。
當(dāng)然，整個流程必須是完備的，測試環(huán)節(jié)必須是嚴(yán)謹(jǐn)?shù)?，開發(fā)環(huán)境，測試環(huán)境，生產(chǎn)環(huán)境應(yīng)盡量保持一致，以此來避免環(huán)境不一致導(dǎo)致的上線失敗。且整個過程中所有的變更，包括代碼變更，部署腳本變更，環(huán)境配置變更都是可追蹤的，便于出現(xiàn)問題之后進(jìn)行回溯與復(fù)盤。這樣，開發(fā)人員就不會擔(dān)心代碼不能夠及時部署到生產(chǎn)線，而運維也不必?fù)?dān)心新上線的代碼會導(dǎo)致系統(tǒng)崩潰。
此外，CI/CD pipeline 有助于縮短應(yīng)用程序的發(fā)布周期，提高應(yīng)用程序的發(fā)布頻率，快速獲得市場反饋，及時作出響應(yīng)。這種良性循環(huán)有助于應(yīng)用程序搶占市場，給企業(yè)帶來效益。
《鳳凰項目: 一個IT運維的傳奇故事》中比爾團(tuán)隊的故事就是對上述過程的一個很好佐證：當(dāng)比爾團(tuán)隊將鳳凰項目的部署流程梳理清楚之后，進(jìn)行了"流水線"(書中雖不叫CI/CD Pipeline，但是內(nèi)容卻是一樣，可以認(rèn)為是CI/CD Pipeline的雛形)改造，在大大提高鳳凰項目發(fā)布頻率的同時，業(yè)務(wù)部門與IT部門之間的矛盾也變得越來越少，公司盈利了，也就避免公司被拆分，IT部門被外包的風(fēng)險。
基于此，CI/CD Pipeline 一般具有以下幾個特點：
標(biāo)準(zhǔn)化的步驟：應(yīng)用程序交付流水線中的構(gòu)建，測試等步驟，一個都不能少，而且環(huán)環(huán)相扣。 可自動部署：從代碼提交那一刻起，一切流程都應(yīng)該是自動的，自動化的好處毋庸置疑：節(jié)省時間，減少人為干預(yù)，避免人為誤操作；"一鍵式"部署讓部署變得簡單。 適用多種語言：CI/CD Pipeline 應(yīng)該適用于大多數(shù)甚至全部語言類型的應(yīng)用程序，java，php，python?？赡苤恍栳槍Σ煌Z言做少量調(diào)整。而不需要每種語言對應(yīng)自己的CI/CD Pipeline。 具備可移植能性：應(yīng)用程序在不同部署環(huán)境下(比如從公有云到私有云，從AWS的Kubernetes 平臺到IBM的Kubernetes 平臺)遷移的時候，Pipeline 可以在不改動或者少量改動的前提下，完成遷移，這樣提高了靈活性，減少了工作量。
三、CI/CD Pipeline 包含的階段
一般來講應(yīng)用程序交付流水線有如下圖所示的幾個階段：
3.1 計劃階段
此階段主要是項目經(jīng)理或產(chǎn)品經(jīng)理從用戶處獲取應(yīng)用程序的相關(guān)信息，從而制定開發(fā)計劃，來對后期開發(fā)進(jìn)行指導(dǎo)。在敏捷盛行的今天，很多公司在此階段都用敏捷來進(jìn)行開發(fā)管理，以迭代的方式來完成用戶故事的開發(fā)。
3.2 編碼階段
這個階段主要是開發(fā)人員通過IDE來進(jìn)行代碼開發(fā)，開發(fā)人員借助于安裝在IDE內(nèi)的一些插件，來編寫符合公司編碼規(guī)范和安全需求的代碼。
3.3 構(gòu)建階段
構(gòu)建階段是可以算是CI/CD Pipeline的真正開始階段，開發(fā)人員在本地完成代碼開發(fā)，并將代碼提交到源碼控制工具(比如git)，此時會觸發(fā)CI流程，進(jìn)行代碼掃描，編譯，單元測試及覆蓋率測試等工作。如果流程是成功的，那么代碼就會被合入主干分支(合并可以是手動，也可以是自動，這取決于項目的開發(fā)模式與規(guī)定)。而一旦某個環(huán)節(jié)出現(xiàn)失敗，都會使得整個流程中斷，并將相應(yīng)信息反饋至開發(fā)人員處。
3.4 測試階段
代碼被部署到測試環(huán)境并展開一系列的測試工作，包括手動的，自動的；功能的，性能的，安全的。需要注意的是，此階段測試所需環(huán)境最好與生產(chǎn)環(huán)境保持一致，避免因環(huán)境不一致導(dǎo)致的上線失敗。
3.5 版本準(zhǔn)備階段
測試階段驗證成功以后，可以認(rèn)為代碼已具備上生產(chǎn)的能力，測試通過的版本被標(biāo)記為可以上生產(chǎn)，只需要手動或者自動操作(取決于項目規(guī)定)就可以將版本推送至生產(chǎn)線上。
3.6 部署階段
將應(yīng)用程序部署到生產(chǎn)線上?？梢圆捎檬謩踊蛘咦詣拥姆绞絹硗瓿刹渴?，同時可以采用藍(lán)綠部署，金絲雀部署等方式來實現(xiàn)"零宕機(jī)"、安全部署。
3.7 維護(hù)階段
應(yīng)用程序上線后，運維團(tuán)隊需要確保應(yīng)用程序運行環(huán)境的穩(wěn)定，在訪問量高的時刻能夠自動擴(kuò)容來應(yīng)對峰值，訪問量低的時候縮容以減少資源消耗。
3.8 監(jiān)控階段
監(jiān)控應(yīng)該包含兩方面的：應(yīng)用程序的監(jiān)控和Pipeline的監(jiān)控，借助于監(jiān)控工具來獲取一些有效數(shù)據(jù)，然后反饋給開發(fā)團(tuán)隊，或者運維團(tuán)隊，以此來進(jìn)一步提高應(yīng)用程序及Pipeline的穩(wěn)定性，安全性。
CI/CD Pipeline 幾乎等同于應(yīng)用程序交付流水線，它與之相對應(yīng)階段的關(guān)系如下圖所示。應(yīng)用程序交付流程從計劃階段開始，而CI/CD Pipeline開始于應(yīng)用程序開發(fā)階段。
四、CI/CD Pipeline 的實現(xiàn)
CI/CD Pipeline 也可以用三步工作法來實現(xiàn)：
第一步：實現(xiàn)從輸入端源碼到輸出端產(chǎn)品的正向流程，將源碼構(gòu)建，測試，版本準(zhǔn)備，部署，運維幾個步驟串起來；
第二步：實現(xiàn)從各個階段至開發(fā)階段的持續(xù)反饋；
第三步：在運行過程中與開發(fā)，安全等團(tuán)隊合作進(jìn)行持續(xù)改進(jìn)。比如，讓部署流程、檢測報告、監(jiān)控信息可視化。
CI/CD Pipeline 的實現(xiàn)要依賴于一些工具，這也就是為什么很多人說DevOps是工具的合集的一個重要原因。雖然觀點不全面，但是工具確實是實現(xiàn)DevOps不可缺少的一環(huán)。
工具的選擇可以遵循以下幾個原則：
擁抱開源
擁抱開源儼然已成為IT行業(yè)的一種新趨勢，開源意味著免費，這可以進(jìn)一步降低企業(yè)成本，另外開放的源代碼對軟件問題的追根溯源有很大幫助，最重要的一點是，可以借助于開源來快速推出有價值的商用產(chǎn)品，比如借助于開源的Linux，Redhat公司推出企業(yè)級的Linux產(chǎn)品；借助于開源的Docker和Kubernetes，亞馬遜，微軟，谷歌，IBM等公司都加速完成了自己企業(yè)級云產(chǎn)品的商用。
社區(qū)強大，用戶數(shù)多
開源工具的選擇必須要考慮社區(qū)的大小和用戶的多少，社區(qū)大，用戶多，開源工具的迭代就快，功能就強大，出問題也能找到相應(yīng)的解決方法。比如 Jenkins，強大的中英文社區(qū)，超過千萬的用戶，讓其變成了最后歡迎的一款持續(xù)集成工具。
豐富的API
CI/CD Pipeline 是工具的集合，工作中心與工作中心的就是工具與工具之間的交互，也就是API的相互調(diào)用，如果一款工具具有豐富的API，那么就比較容易將其整合進(jìn)CI/CD Pipeline。比如Github，就有關(guān)于release，commit，pull request等各種API。
易學(xué)易用
一款工具能夠快速上手，容易使用，就能夠加速CI/CD Pipeline的開發(fā)，降低CI/CD Pipeline的維護(hù)難度，大大減少了工作量。
五、CI/CD Pipeline 發(fā)展趨勢
CI/CD Pipeline 一直在發(fā)展演進(jìn)，其主要的發(fā)展變化有以下幾點：
5.1 云原生
CI/CD Pipeline 的發(fā)展方向跟應(yīng)用程序是一樣的：云原生。有一些云原生的CI/CD Pipeline工具，比如Jenkins，Tekton等已經(jīng)出現(xiàn)，它們能夠進(jìn)一步提高CI/CD Pipeline的效率，加速云原生應(yīng)用程序的構(gòu)建。
5.2 GitOps 和ChatOps
GitOps 和 ChatOps 將占據(jù)重要的戲份。GitOps 和ChatOps 可以將團(tuán)隊，工具，流程，自動化等組成一個高效的、透明的工作流，工作進(jìn)度一目了然，所有變更可控、可回溯跟蹤，產(chǎn)品的研發(fā)效率會隨著團(tuán)隊之間溝通協(xié)調(diào)效率的增加而提高。
Github Action就是GitOps的一個典型例子。Slack 的bot 就是ChatOps的一個典型例子。
5.3 平臺化
平臺化的好處毋庸置疑：通過將工具，流程的有效整合，使得軟件開發(fā)生命周期的整個流程透明化，數(shù)據(jù)可視化，部署流程自動化，為持續(xù)反饋，持續(xù)改進(jìn)提供重要依據(jù)。
六、CI/CD Pipeline 的一些反模式
6.1 與開發(fā)沒有關(guān)系
開發(fā)人員對于Pipeline的認(rèn)識不足，開發(fā)模式不做任何改變。代碼提交頻率沒有提升，可能是三天一次，甚至是一個新功能提交一次。這樣就不能充分發(fā)揮Pipeline所帶來的優(yōu)勢，產(chǎn)品發(fā)布頻率就不高。此外，開發(fā)認(rèn)定的工作范圍只是到提交完代碼的那一刻，不去關(guān)心整體流程的成功與否，不去獲得持續(xù)反饋信息。一旦出問題了，就直接找運維。一次次的 "穿新鞋，走老路" 也就導(dǎo)致DevOps 轉(zhuǎn)型的失敗。
6.2 構(gòu)建時間太長
為了保證代碼質(zhì)量，實現(xiàn)一鍵式部署，Pipeline會集成所有的步驟，Pipeline就顯得格外臃腫，一次構(gòu)建需要幾十分鐘，甚至幾個小時(比如采用appscan完成代碼的動靜態(tài)掃描)。開發(fā)人員不愿意提交一次代碼，等待如此長時間的構(gòu)建。就會降低代碼提交頻率，一次提交多個變更。由此，Pipeline成了提高產(chǎn)品發(fā)布頻率的瓶頸，持續(xù)集成和持續(xù)部署就更無從談起了。Pipeline應(yīng)支持產(chǎn)品隨時隨地部署，可以一天完成多次部署要求。就好比一條路，不限制上面跑的是人還是車，跑多快，有多少。
6.3 反饋信息簡單
當(dāng)某個步驟的失敗導(dǎo)致整個流程終止時，僅僅用一句構(gòu)建失敗來通知相關(guān)人員。這種不明確的通知就需要相關(guān)人員齊上陣一起查處問題的根源，這是一種浪費。構(gòu)建過程中產(chǎn)生的信息應(yīng)盡量詳細(xì)，比如代碼編譯失敗，單元測試失敗，鏡像檢測有漏洞等。如果是微服務(wù)，還應(yīng)該明確是哪個服務(wù)。這樣在第一時間就有相應(yīng)的責(zé)任人去快速修復(fù)。
6.4 漏洞是安全團(tuán)隊的事情
當(dāng)掃描出安全漏洞時，都認(rèn)為是安全團(tuán)隊的工作范疇。報告在，沒人管。其實，安全的范圍很大，錯誤的配置信息，代碼中的敏感信息，都算是漏洞。不同層面的漏洞應(yīng)該有不同的團(tuán)隊來負(fù)責(zé)，比如與應(yīng)用程序代碼相關(guān)的應(yīng)該是開發(fā)團(tuán)隊負(fù)責(zé)，與基礎(chǔ)設(shè)施相關(guān)的應(yīng)該是運維團(tuán)隊負(fù)責(zé)，而且兩個團(tuán)隊?wèi)?yīng)該與安全團(tuán)隊協(xié)調(diào)合作，共同修復(fù)漏洞。
6.5 不合理的人工干預(yù)
當(dāng)修復(fù)緊急故障的代碼覆蓋率不達(dá)標(biāo)，但又不得不上線時，通過降低，甚至取消代碼覆蓋率檢測來使Pipeline成功；當(dāng)Pipeline在最后一步失敗時，為了節(jié)省時間，避免重新構(gòu)建時，通過手動修改流程或者配置來完成Pipeline。這種為了節(jié)省時間而引入的不合理的人工干預(yù)，破壞了Pipeline的完整性，人工干預(yù)是不可追蹤的，引起的故障很難回溯。Pipeline 是一個流程，既然是流程，就應(yīng)該根據(jù)流程走。
6.6 害怕失敗
害怕構(gòu)建失敗，失敗就意味著代碼有問題，大家集體炸鍋。為了每次構(gòu)建都得到綠色的結(jié)果，調(diào)低檢測閾值，剪掉經(jīng)常出錯的步驟，最后是開發(fā)happy，運維happy，測試happy，大家集體happy。其實，失敗是持續(xù)改進(jìn)的推動力。持續(xù)改進(jìn)的Pipeline才是實用的Pipeline。
七、結(jié)束語
可以看到，"流程 + 工具 + 自動化 ≈ CI/CD Pipeline" 。也就不難理解，為什么會有DevOps就是流程，就是工具的集合，就是自動化等這些誤區(qū)的存在。DevOps是一場文化運動，CI/CD Pipeline是這場運動在企業(yè)落地實踐的強有力手段。
附錄
下圖是基于Kubernetes平臺的一個CI/CD Pipeline 示例，僅供參考。
圖中出現(xiàn)的工具均為開源工具，但不是說圖中出現(xiàn)的工具就是最好的，必選的，工具的選擇需根據(jù)前述原則來進(jìn)行。 最下面的屬于監(jiān)控系統(tǒng)，通知系統(tǒng)，每套環(huán)境都用到了，而且貫穿整個流程。所以只畫一次。 CI 流程如果成功，既可以手動也可以自動部署測試環(huán)境；同樣的，如果測試環(huán)境測試成功，既可以手動也可以自動部署生產(chǎn)環(huán)境。以此完成CD流程。
作者：馬景賀
馬景賀，人稱小馬哥，花名逍遙子。曾做過LTE 4G網(wǎng)絡(luò)協(xié)議開發(fā)，后轉(zhuǎn)向 DevOps，對于Cloud Native DevSecOps進(jìn)行布道，喜歡研究docker，kubernetes，istio等Cloud Native相關(guān)技術(shù)，樂于分享，運營著DevOps SIG公眾號。曾在大連DevOps社區(qū)活動上，舉辦DevOps Workshop活動。
參考資料
《鳳凰項目 一個IT運維的傳奇故事》作者 (Gene Kim, Kevin Behr，George Spafford),人民郵電出版社
《DevOps 實施手冊 在多級IT企業(yè)中使用DevOps》作者 (Sanjeev Sharma),清華大學(xué)出版社
https://opensource.com/article/19/4/devops-pipeline
https://www.red-gate.com/simple-talk/sysadmin/devops/introduction-to-devops-the-application-delivery-pipeline/
https://devops.com/continuous-delivery-pipeline/
https://www.plutora.com/devops-at-scale/pipeline
https://medium.com/taptuit/the-eight-phases-of-a-devops-pipeline-fda53ec9bba
