實施有效有價值的CI / CD流水線實踐分享

• 2020 年 3 月 17 日
• 筆記

原文地址： https://medium.com/@sanjayaben/how-to-build-an-efficient-ci-cd-pipeline-b5738ad567c8 我覺得這篇文章真的能學到很多理論知識，便於我們實施流水線。

在過去幾年中，持續集成和持續交付一直是許多敏捷軟體開發團隊的首要任務。它被認為是建立DevOps實踐的基礎，大多數組織將其視為實現快速可靠的軟體交付的關鍵推動力。

持續交付是敏捷軟體開發中的核心思想。《敏捷宣言》中最早的一項原則可以追溯到2001年，內容如下：

「我們的首要任務是通過儘早並持續交付有價值的軟體來滿足客戶。」

敏捷軟體開發的成功在很大程度上取決於團隊能否迅速向最終用戶推出功能並結合最終用戶的回饋不斷改進軟體。周期越短，用戶滿意度就越高。有效的CI / CD管道將是實現如此快速周轉的關鍵。

基本原理

很少有驅動CI / CD管道的基本原理。

• 集成和驗證 —在典型的軟體開發設置中，您期望多個開發人員在自己的功能分支中進行開發，並將其定期集成到一個公共的開發分支中。集成（或甚至在集成之前）一段程式碼時，必須要有一個驗證步驟，該步驟可以快速確保特定的集成不會破壞現有功能，不會降低性能甚至不會引入安全漏洞。
• 自動化 -為了提高速度，必須使驗證自動化。即，它應該由一系列自動化測試組成，這些測試將覆蓋軟體的大多數關鍵方面，並且可以在合理的時間內執行。
• DevOps文化 -開發團隊在確保管道的連續性方面可以發揮重要作用。例如，當構建失敗或測試失敗時會發生什麼？解決此類問題應放在首位，否則將減少CI / CD流程的收益。
• 容器化 -不是強制性的，但是如果部署基於容器，則將降低複雜性。

我們的方法

設計用於交付企業應用程式的CI / CD管道不僅需要考慮基礎知識，還需要考慮組織或軟體特有的實際挑戰。需要考慮的幾點是

• 軟體開發過程 -CI / CD將在敏捷環境中產生最佳的ROI。
• 單元測試覆蓋率 —這是CI的關鍵部分，如果您的測試覆蓋率很低，那麼在實施CI / CD管道之前就應該先進行處理。
• 自動化程度 –這將決定您是否僅依賴自動化測試，還是要在流程中引入一些手動測試。
• 測試套件的性質-測試用例的數量或更重要的是，可能需要考慮執行測試所花費的時間。例如，如果測試需要很長時間才能運行，那麼在每次程式碼提交時執行它們可能並不實際。

在我們的案例中，我們採用了以下四步方法。

持續交付和持續部署經常被混淆，但這是兩回事。馬丁·福勒（Martin Fowler）將差異描述如下，

「持續交付有時會與持續部署相混淆。持續部署意味著每項變更都將貫穿整個流程並自動投入生產，從而導致每天進行許多生產部署。連續交付只是意味著您能夠進行頻繁的部署，但可能會選擇不進行部署，通常是由於企業偏向於降低部署速度。為了進行持續部署，您必須進行持續交付。」

全自動持續部署通常被認為是業務風險，尤其是在企業設置中。這就是為什麼存在一個「發布過程」的原因，在該過程中，更改將被系統地，可預測地交付給最終用戶。

持續集成

當開發人員將程式碼提交到其相關功能分支時，將觸發我們的CI流程。現在，與Git存儲庫關聯的Git掛鉤將觸發Jenkins集群中的構建過程。Jenkins管道用於驅動構建過程，並且存在與構建過程相關的品質關卡檢查。品質門檢查應基於對共同開發部門的最低要求。在我們的上下文中，品質門檢查可以驗證，

• 構建是否成功
• 單元測試已通過
• 沒有違反程式碼風格的行為
• 新程式碼的程式碼覆蓋率超過80％
• Sonar掃描未報告任何漏洞或程式碼氣味。

持續交付

如果品質門已經通過，則開發人員可以提交其拉取請求。集成管理器會將程式碼合併到通用開發分支。這將啟動通用開發分支上的構建過程，如果成功，將繼續構建docker映像。

理想情況下，所有測試都應作為集成過程的一部分執行，但實際上由於測試執行時間的原因，這效率很低。因此，我們將其設計為一個稱為「連續測試」的過夜時段。

持續測試

這是一個通宵的過程，其中會在軟體的最新成功構建上執行功能測試，安全掃描和性能測試等測試。在執行測試之前，將根據最新的docker鏡像將新容器部署在連續測試環境中。連接到Kubernetes集群的永久卷將作為測試的前提條件被還原。請注意，所有這些活動都是計劃的並且是完全自動化的。

第二天早上在每日站立會議之前檢查測試報告。任何腳本問題將由品質保證團隊解決，而任何程式碼問題將由開發團隊解決。CT故障被認為是優先考慮的問題，並將在最早的情況下得到解決。

受控部署

由於大多數艱苦的工作已經在前面的三個步驟中完成，因此簡化了部署。成功的CT周期是唯一的資格標準，可以在任何時候進行發布。發行腳本將

• 用相關版本號標記Docker映像
• 用版本號標記源存儲庫

現在，可以將發布版本部署在發布管道中的其他環境中。最終，將發行版推廣到生產將是業務決策。docker + kubernetes設置將簡化部署過程，並且結果在所有環境中都是可預測的。

可用技術

在我們的案例中，我們選擇使用工具組合，因為它似乎可以為我們的複雜需求提供最佳解決方案。大多數開發企業產品的團隊將從這種全新的方法中受益。我們的工具棧包括

• Jenkins以主從模式作為構建伺服器
• Jenkins Pipelines推動CI流程
• Git Hooks通過程式碼提交觸發構建
• SonarQube作為程式碼品質工具
• 用於自動化功能測試的機器人框架
• JMeter性能測試
• OWASP ZAP用於安全掃描

結論

高效的CI / CD管道可以大大縮短產品上市時間，並有助於保持所交付軟體的穩定性和品質。但是，成功的實施不僅需要正確的技術，還需要關鍵利益相關者的承諾。項目發起人在投資時應具有長遠眼光，技術領導者在推動轉型中起著