一千萬個為什麽

搜索

選擇整合分支戰略會成為DevOps的一部分嗎?



成熟的 DevOps組織中,選擇產品/產品線集成分支戰略是DevOps的一部分嗎?

整合分支戰略意味著什麽?

例如,產品團隊必須在一定的時間間隔內集成20項功能,以滿足一定的上市時間要求。

一種可能的方法是以瀑布方式使用功能分支,就像他們已經做了很多年一樣 - 每個功能都在他們自己的分支中開發和測試,並且僅在合並到主分支(從中釋放分支將被從中拉出)之後達到各自的功能質量保證目標。

但總積分時間估計值 - 20個特征分支合並窗口乘以平均合並時間(來自團隊的分支合並歷史數據)可能過高。

另一種方法是拉出4個中間集成分支,其中每個分支由5個特征分支使用。這樣,所有20個特征將被合並到5個分支合並窗口間隔中的4個中間分支中。接下來是4個其他分支合並窗口時間間隔,用於將這4個分支合並到主分支中,從而使總集成估計值達到9個窗口,遠遠優於20個窗口。是的,某些收益可能會被更高程度的最後4次合並的難度。

另一種方法是直接進行基於主幹的開發(真正的CI集成到主分支),幾乎沒有分支合並。

選擇一種這樣的策略的過程就是我所說的分支策略。

註意:實際的SCM存儲庫是無關緊要的,它可以是作為一個單獨管理的repos的任意組合,術語 branch 表示該組合中存在的任何物理/實際repo分支的公共邏輯表示。

轉載註明原文: 選擇整合分支戰略會成為DevOps的一部分嗎?

一共有 2 個回答:

DevOps應參與此決策,但開發人員,產品經理,測試人員,支持人員以及可能的銷售和營銷人員在某種程度上也是如此。

分支戰略可能會影響最終產品的發布,所以它不應該是一個團隊的決定。

分支策略是一個非常明顯的業務決策,DevOps工程師應該成為主要專家,解釋所有的權衡。在這個問題上社會上有一些強有力的立場,非常清楚Jez Humble與他的持續交付書一方。你可以看到他在這裏談論它。這個主題的專家組將會是視頻。這裏是我高調推薦的回答 StackOverflow專門針對功能分支的主題。很明顯,這是DevOps的一大話題。

人們常說的一件事(主要是Jez Humble)是特征分支是邪惡的。您將需要一個(n-1)(n-2)/ 2合並n個獨立特征分支的 [組合數n-1超過2] 。在10個以上的功能分支中有一些非常高的數字。由於合並非常困難,而且沒有公開的版本控制系統,所以整個軟件行業正在從軟件版本和軟件開始轉向軟件即服務,唯一的方法就是向前發展,並且開發和維護軟件由供應商為你。

據我所知,只有一家公司可以在公司內部完成高質量的關鍵業務軟件,並保留了過去10多年的主要版本,通過多次代碼重構反向移植補丁程序,並且能夠定期處理數十個程序每個版本的主要功能分支和在其各個功能分支上開發的數千個小功能,並不斷作為完整功能合並而不是單獨提交。該代碼也已在14種不同的架構上發布。該公司是甲骨文公司,產品是RDBMS,自從至少在1990年以來,他們一直在實踐現在稱為DevOps的事業。2001年的數百次代碼部署將是非常標準的。他們能夠做到這一點的原因是通過嚴格的編碼標準,不變的測試套件和我花了10多年的時間開發的專有版本控制系統。一個系統可以通過自動化完成99%的合並。

其他人幾乎都只修補了某個項目的某個階段/大小的最新主要發行版本,或者需要大量人力資源才能將所有修補程序合並到所有可能的發行版本以及大量人力或計算資源以測試商場。例如,在Linux內核中,您將擁有X.odd開發版本的維護人員以及X.even版本的後續穩定分支維護人員,但是您不會看到X-1.Y版本的修補程序。有時Linux發行版將在其LTS發行版中維護內核版本,但這些版本的成本很高,並且代碼質量各不相同。這是一個高度可見的項目,投入了大量資源。

造成這種差異的主要原因是:

  1. 遵守編碼標準和代碼樣式
  2. 通過不變測試套件的全面覆蓋,可以捕獲沒有專門編寫測試的錯誤。
  3. 能夠實現高級自動化的版本控制系統。