持續(xù)集成和交付流水線的8個反模式 | IDCF

來源：Thoughtworks洞見

作者：馮煒

原文發(fā)表：原文發(fā)表于：https://www.rea-group.com/blog/continuous-integration-and-delivery-pipeline-mistakes/

一、CI/CD & Pipeline

隨著DevOps的理念在眾多公司的采納，CI/CD也漸漸落地。

• CI（Continuous Integration）持續(xù)集成，是把代碼變更自動集成到主干的一種實踐。CI的出現(xiàn)解決了集成地獄的問題，讓產(chǎn)品可以快速迭代，同時還能保持高質(zhì)量。它的核心措施是，代碼集成到主干之前，必須通過一系列自動化測試，比如編譯、單元測試、lint、代碼風(fēng)格檢查。
• CD包括持續(xù)交付和持續(xù)部署。持續(xù)交付（Continuous Delivery）指的是團(tuán)隊自動地、頻繁地、可預(yù)測地交付高質(zhì)量軟件版本的過程，可以看做持續(xù)集成的下一個階段，強(qiáng)調(diào)的是無論代碼怎么更新，軟件都是隨時可以交付的；持續(xù)部署（continuous deployment）更強(qiáng)調(diào)的是使用自動化測試來保證變更的正確性和穩(wěn)定性，以便在測試通過后立即部署，是持續(xù)交付的更進(jìn)一步。二者的區(qū)別是，持續(xù)交付需要人為介入，需要確?？梢圆渴鸬缴a(chǎn)環(huán)境時，才去進(jìn)行部署。

二、CI/CD Pipeline的反模式

• 該并行的任務(wù)沒有并行執(zhí)行，等待的任務(wù)拉長了執(zhí)行時間；
• 執(zhí)行Pipeline的agent節(jié)點太少，或者性能不足，導(dǎo)致排隊時間太長，效率太低；
• 執(zhí)行的任務(wù)太重，相同測試場景被不同的測試覆蓋了很多次。比如同樣的邏輯在不同測試中都測了一遍；
• 沒有合理利用緩存，比如每個任務(wù)里都要下載全部依賴，在構(gòu)建Dockerfile時沒有合理利用layer，每次都會構(gòu)建一個全新的image。

• 檢查Pipeline的設(shè)計是否合理，盡可能讓任務(wù)并行;
• 對代碼的各種測試深入了解，讓測試盡量正交，避免過多的重復(fù)；
• 檢查代碼中的依賴，合理利用好緩存。包括Docker Image、Gradle、Yarn、Rubygem的緩存，以及Dockerfile是否合理的設(shè)計，最大化的將不可變的layer集中的開始階段；
• 檢查執(zhí)行構(gòu)建的節(jié)點資源是否充足，能否在任務(wù)量大時做彈性伸縮，減少等待和執(zhí)行時間。

• 提升測試的穩(wěn)定性，比如用mock替代不穩(wěn)定的源。
• 采用Pipeline的重試功能，或者采用穩(wěn)定的鏡像源，或者提前構(gòu)建好基礎(chǔ)鏡像。
• 引入Pipeline的插件保證任務(wù)不會并行執(zhí)行。

• Pipeline的定義跟構(gòu)建工具緊密耦合，包含了Pipeline工具特有的參數(shù)以及CLI命令。比如在配置中使用BUILDKITE_BUILD_NUMBER，BUILDKITE_QUEUE等等。結(jié)果就是本地運行的方式或結(jié)果和Pipeline上運行的方式以及結(jié)果不一致。
• 在Pipeline的任務(wù)中寫了一大段腳本，或者直接使用命令加上一堆參數(shù)，以至于在本地想跑測試需要在Pipeline的配置中找命令并且在本地粘貼。
• 不做環(huán)境隔離， 測試，編譯，部署等都依賴于運行時環(huán)境?？赡艹霈F(xiàn)Pipeline 因依賴的軟件/庫等版本不一致而導(dǎo)致的不一致的情況，通常還很難排查。

最后