持續交付實踐-pipeline 使用之 MultiBranch Pipeline

前言

在探討multiBranch Pipeline之前，很有必要先探討下如何制定有效的代碼分支管理規範，使用高效的版本控制系統，並對構建產物及其依賴進行管理。

我們首先要強調，需要進行版本控制的不僅是源代碼，還有測試代碼、資料庫腳本、構建和部署腳本、依賴的庫文件等，並且對構建產物的版本控制也同樣重要。只有這些內容都納入版本控制了，才能夠確保所有的開發、測試、運維活動能夠正常開展，系統能夠被完整的搭建。

制定有效的分支管理策略對達成持續交付的目標非常重要。看過《持續交付》這本書的同學都知道，持續交付建議的方式是基於主幹的開發（Trunk Based Development，TBD）模式，所有開發者在主幹上頻繁的提交代碼，然後通過持續集成的機制，對修改觸發快速的自動化驗證和反饋，Google就在堅持使用主幹開發模式，所有人的所有更改直接提交到Trunk上。那持續交付為什麼這樣建議呢，實際應用中又是否能夠適用？

常見分支管理策略

1.基於主幹的開發

前面已經介紹過了《持續交付》更傾向使用基於主幹的開發模式，所有項目成員把代碼都提交到主幹上，提交後自動觸發持續集成進行驗證和快速反饋，通過頻繁的集成和驗證，在保證質量的同時提升效率。主幹開發模式非常強調代碼提交習慣，包括頻繁、有規律的代碼提交（比如每人每天提交一次），而提交前需要進行充分的本地驗證和預測試，以保證提交質量，降低污染主幹代碼的概率。

優點：

相比於分支開發，主幹開發模式有很多優勢。首先是代碼提交到主幹，可以做到真正的持續集成，在衝突形成的早期發現和解決問題，避免後期的」合併地獄」，這樣的整體成本才是最低的。

對持續集成來說，具體實施也將會變的非常簡單，只需要維護一條pipeline交付流水線，通過git的hook機制，當有新代碼提交的時候就會觸發pipeline的執行並反饋結果，如果有問題代碼提交人員必須要實時去解決。

難點：

主幹開發模式有很多優勢，但具體實施過程中會發現，當一個項目開發者多了以後，如果沒有強力的制度約束和相關意識支撐，推動起來會碰到不少的困難，比如：

主幹上功能開發完成時間有先有後，如果遇到有未完成的功能但又需要發布時，就需要一種方法屏蔽掉未完成功能，才能進行安全的發布

主幹上功能開發完成後，如果需要比較長的時間進行驗收測試，那麼此時為了確保發布功能的穩定性且所有功能是經過驗證的，可能會限制新功能的提交，有的團隊採用的封版、凍結主幹的做法就是這種情況，這樣的確會影響開發效率

如果修改的功能非常複雜，或者要進行架構上的大範圍重構，以上問題就更加明顯和難以解決了

如果團隊規模比較大，同時工作在主幹上的開發人員比較多，那麼衝突的概率會比較大，持續集成的失敗率可能比較高

這些問題並不是無解，比如通過功能拆解合理規劃需求進行增量開發；通過配置隱藏未完成功能；以微服務的思想對大的架構進行拆分組件，每個組件獨立開發和部署等。前提是我們的系統要有良好的架構設計，以及我們的開發者要有良好編碼協作習慣。

2.基於分支的開發

這正是很多團隊經常默認使用的模式，具體表現為接到需求後拉出分支，後面的開發都在分支上提交，每個分支生命周期較長，並且可能有多個並行分支，直到快要上線時或者上線後才合併到主幹。

優點：

多個功能可以完全並行開發，互不干擾。還可以按每個功能特性拉出分支，那麼每次提交都是完整的功能特性，分支劃分明確、版本控制的記錄也會比較清晰易懂。並且由於不同需求的開發進度不同，可以選擇某個先開發完成的功能特性進行合併、發布，而不會被其它分支上未完成的功能特性阻塞。

缺點：

引用電影《無間道》中的一句話，「出來混，總有一天要還的」，因為雖然使用分支暫時隔離了不同功能的代碼，但系統的多個功能或者多個組成部分最終還是要集成在一起工作的。如果不同分支代碼之間有交互，合併時可能會有大量衝突需要解決。

在實際項目中，進行代碼合併時通常很容易出錯，解決衝突也非常耗時，特別是到代碼合併時基本都已經到了項目後期，經常出現合併錯誤甚至遺漏合併的問題，對於QA來說，每個分支通過測試後，合併代碼以後又需要系統的重新測試一次，工作量巨大不說還很容易導致一些合併造成的bug遺漏到線上，經歷過的同學都曾體會過這種方式的痛苦。

對於持續交付來說，每條分支我們都需要搭建一條完整的pipeline與之對應，這意味著需要更多的部署環境和更多的重複測試，在合併代碼後所有的過程還需要重新來一遍以避免各種代碼合併錯誤。

3.權衡和建議

在某些情況下，有時迫不得已要採用分支開發的模式，比如並行需求太多且相互干擾，比如開發團隊的習慣無法驅動改變，拉出分支其實意味著已經在持續集成/持續交付上做出了妥協，那麼我們建議至少要使用一些折中的方案。

盡量縮短分支的周期，最長也不要超過迭代周期；

每個分支上運行單獨的測試流水線，保證質量。雖然這種方式浪費資源，而且其實也沒進行」真正的「集成；

分支只與主幹合併代碼，分支彼此之間盡量不做合併；

分支定期合併主幹上的變更。

具體到Jenkins Pipeline的實施，個人認為主幹開發模式，或者分支比較少的分支開發模式，原來的普通pipeline模式已經足夠。但如果是並行分支比較多的分支開發模式，以個人實踐經驗，單條pipeline使用時衝突會變的比較嚴重，雖然pipeline也可以通過參數化的方式去適配多個分支使用，但這種方式的缺點是每個分支的結果可視化會變的比較糟糕，這種情況下我們更推薦使用MultiBranch Pipeline。

MultiBranch Pipeline

前面啰嗦了這麼多，終於到了重點要介紹的multiBranch Pipeline部分內容，但理解持續交付的分支管理策略確實對我們pipeline的具體使用非常重要。

之前已經介紹過了，Pipeline as Code是2.0的精髓所在。multiBranch Pipeline簡單來說，可以理解為是一個項目里所有分支代碼pipeline的集合。它的使用首先需要在每個分支代碼的根目錄下存放Jenkinsfile（Pipeline的定義文件），我們可以理解下maven的pom.xml文件，Jenkinsfile作為pipeline的管理文件也需要在源代碼中進行直接的配置管理。這就要求devops工程師（QA、運維等）首先要有代碼庫的許可權，或者至少賦能給dev工程師jenkinsfile的設計能力。

1.新建multibranch pipeline job

對代碼地址和jenkinsfile路徑進行配置如下

2.自動為每個branch生成job

在multibranch pipeline job保存後，jenkins自動地檢查所有的branch，且自動地為所有的branch創建job,當然前提是存在jenkinsfile文件

例如上面的job，自動地生成了文件夾pipeline_expertPatient_multiBranch，且在此文件夾下自動地為trunk和branch生成了job。如果在代碼庫上某個branch分支被刪除，multibranch pipeline也會自動檢測變化並刪除相應的job。

3.Scan Multibranch Pipeline Now

第一次生成Multibranch Pipeline時，會自動掃描pipeline配置文件並建立相應的job,後續如果jenkinsfile文件有變更，也可以手動觸發掃描，日誌輸出如下

這樣一個完整的MultiBranch Pipeline就建立完成，你可以根據不同的分支定製不同的pipeline策略，當然也可以採用參數化的方式使用通用的jenkinsfile文件。

結語

MultiBranch Pipeline可以理解為是針對某個工程所有分支代碼的pipeline集合，jenkins會自動發現源代碼中的jenkinsfile配置文件生成對應的分支job。

而MultiBranch Pipeline要求jenkinsfile配置文件存放在源代碼的方式，也是符合Pipeline as Code的理念。雖然這也會給一些沒有代碼提交許可權的devops工程師帶來困擾。

主帖直達：https://testerhome.com/topics/9977

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！