在持續集成中處理多個分支

我一直在處理在我公司擴展CI的問題，同時試圖找出在CI和多個分支時採用哪種方法。在stackoverflow有一個類似的問題，Multiple feature branches and continuous integration。我已經開始了一個新的討論，因爲我希望得到更多的討論並在問題中提供一些分析。在持續集成中處理多個分支

到目前爲止，我發現我可以採取兩種主要方法（或者其他一些方法）。

多組作業每個分支（談論詹金斯/哈德遜在這裏）
- 寫的工具來管理多餘的工作
  - 創建/修改/批量刪除作業
  - 自定義設置對於每個分支的每個作業（SCM URL，dep管理repos重複）
  - 人們用shell工具，ant腳本和Jenkins CLI解決這個問題的一些例子。請參閱：
- 會導致您的CI集羣上更多的負載
- 反饋循環減慢（如果基礎設施不能處理新的負載）
多集的每2個分支（DEV &穩定）
- 手動管理兩套（如果你更改作業下的conf然後一定要在其他分支改變）
  - PITA但至少這麼幾個管理
- 其他額外分支不會得到一個完整的測試套件，他們被推到dev
- 不滿意的開發者。爲什麼開發人員應該關心CI縮放問題。他有一個簡單的請求，當我分支時我想測試我的代碼。簡單。

如此看來，如果我想爲自己定製分支機構提供CI的開發者，我需要詹金斯（API或shellscripts還是什麼？）特殊加工和處理縮放。或者我可以告訴他們更經常地合併到DEV，並在沒有CI的自定義分支上生活。你會選擇哪一個或有其他選擇？

來源

2011-04-10 toomasr

當您談論縮放CI時，您確實在談論如何擴展CI服務器的使用範圍，以處理您的主線所有功能分支。最初，這看起來是一種很好的方法，因爲分支機構的開發人員可以獲得CI作業包含的自動化測試的所有優勢。但是，遇到管理CI服務器作業的問題（就像您發現的那樣），更重要的是，您並不是真的在執行CI。是的，您正在使用CI服務器，但您並未持續集成所有開發人員的代碼。

執行真正的CI意味着您的所有開發人員都定期致力於主線。容易說，但最難的部分就是在不破壞你的應用的情況下做到這一點。我強烈建議你看看Continuous Delivery，尤其是保持你的應用程序可釋放部分第13章：管理組件和依賴關係。要點是：

隱藏新的功能，直到它完成（A.K.A Feature Toggles）。

將所有更改作爲一系列小的更改逐漸進行，每個更改都是可釋放的。

使用抽象分支對代碼庫進行大規模更改。

使用組件來分離應用程序中以不同速率更改的部分。

它們是非常明顯的，除了抽象分支。這僅僅是一個奇特的期限：

在您需要更改系統的一部分，創建一個抽象。

重構系統的其餘部分以使用抽象層。

創建一個新的實現，它不是生產代碼路徑的一部分，直到完成。

更新您的抽象層以委託給您的新實現。

刪除舊的實現。

如果抽象層不再合適，則移除該抽象層。

從分行，溪流和持續集成節以下段落中第14章：高級版本控制總結了影響。

增量方法當然需要更多的紀律和關懷 - 甚至更多的創造力 - 比創建分支和潛水gung-ho重新設計和開發新功能。但它大大降低了您的更改破壞應用程序的風險，並且可以爲您和您的團隊節省大量的時間合併，修復破壞以及讓您的應用程序進入可部署狀態。

放棄特徵分支需要相當的思維轉換，並且總是會遇到阻力。以我的經驗來看，這種抵制是基於開發人員並不安全的將代碼作爲主線，這是一個合理的擔憂。這反過來通常是由於缺乏上述技術的知識，信心或經驗以及可能缺乏對自動化測試的信心。前者可以通過培訓和開發人員支持來解決。後者是一個更難處理的問題，但分支並不提供任何額外的真正安全性，它只是推遲問題，直到開發人員對代碼足夠自信。

來源

2011-04-19 01:42:04

湯姆，這隻有在1）發佈和更新都比較容易的情況下才能很好地發揮作用。2）你的大部分改變都很好地隔離了。這對於web開發人員來說是正確的，但是如果你正在做盒裝產品發佈，那麼穩定版本必須不惜一切代價保持穩定，因爲修補程序在大型企業環境中非常昂貴或者甚至是不可能的。 – 2011-04-19 06:33:14

+13

真正的CI不僅僅是整合，也是關於反饋 – 2011-04-19 06:33:58

我選擇這個作爲答案（至少給了賞金，請讓我知道如果我仍然需要標記它是正確的），但我認爲這不是解決我的問題。我已經在http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ – toomasr 2011-04-20 13:10:01

我會爲每個分支設置單獨的作業。我之前完成了這項工作，如果您正確設置了Hudson/Jenkins，則不難管理和設置。創建多個作業的快速方法是從具有相似需求的現有作業複製並根據需要進行修改。我不確定是否要讓每個開發人員爲他們自己的分支機構設置自己的工作，但是對於一個人（即生成管理人員）來管理它並不是很多工作。一旦自定義分支合併到穩定分支中，相應的作業就可以在不再需要時被刪除。

如果您擔心CI服務器上的負載，您可以設置CI的單獨實例，甚至可以設置單獨的從站以幫助平衡多個服務器之間的負載。確保運行Hudson/Jenkins的服務器已經足夠。我已經使用了Apache Tomcat，並且必須確保它具有足夠的內存和處理能力來處理構建隊列。

重要的是要清楚你想用CI來實現什麼，然後找出一個方法來實現它，而不需要手動或重複。使用CI服務器執行的其他外部工具或腳本可以幫助簡化整個構建管理流程，這沒有任何問題。

來源

2011-04-12 15:27:48 Bernard

我覺得這種缺乏工具意味着有餘地一些插件/產品在這個部門。不想寫我自己的。 – toomasr 2011-04-14 07:53:11

Jenkins有一個實用程序可以自動爲每個分支創建配置配置：http://entagen.github.com/jenkins-build-per-branch/ – kolen 2012-11-09 13:21:20

我會選擇dev + stable分支。如果您仍然需要自定義分支並擔心負載，那麼爲什麼不將這些自定義分支移動到雲端，讓開發人員自己管理它們，例如http://cloudbees.com/dev.cb 這是Kohsuke現在的公司。還有一個Eclipse工具，所以如果你在Eclipse上，你將會緊密集成到dev env中。

來源

2011-04-14 07:01:05

我會交易缺乏管理多個分支的工具問題，但在雲端？我的意思是我現在可以管理負載，但仍然不是分支機構？ – toomasr 2011-04-14 07:50:31

我的意思是忘記工具並在開發人員之間分配管理 - 「如果您想要自定義個人版本，這裏是您的CB賬戶」。不影響主服務器的構建性能。雖然他們的API非常簡單，但創建管理實用程序可能只需要兩週的時間，然後您可以在那裏執行任何操作。正如生活中的平常一樣，如果你想要特別的東西，你最好自己做。與此同時，他們正在快速增長並傾聽社區，因此請填寫功能請求並可能很快出現。 – 2011-04-14 10:10:09

哦，理解。按照他的意願，告訴分支機構所有者櫻桃選擇自己感興趣的工作，並將其設置爲自定義分支。我喜歡這個想法。 – toomasr 2011-04-15 07:44:46

其實真正有問題的是構建與功能分支的隔離。在我們公司，我們有一套獨立的Maven項目，都屬於更大的發行版。這些項目由不同的團隊維護，但對於每個分配，所有項目都需要發佈。現在特徵分支可能會從一個項目重疊到另一個項目，而當構建隔離變得痛苦的時候。有幾種解決方案，我們已經試過：

在專用的奴隸創造承上啓下另外的快照庫爲每特性分支
份額本地資源庫
使用存儲庫服務器插件與上游資源庫
使用一個私人存儲庫構建所有內部工作

事實上，最後的解決方案是最有前途的。所有其他解決方案缺乏一種或另一種方式。與job-dsl插件一起，很容易建立一個新的功能分支。只需複製並粘貼groovy腳本，調整分支並讓種子工作創建新的工作。確保種子作業刪除不受管理的作業。然後，您可以輕鬆使用不同Maven項目的功能分支進行縮放。

但是正如湯姆所說的那樣，如果克服功能分支的必要性並教導開發人員整合，但這是一個更長的過程，並且結果並不清楚，許多遺留系統部分您不會再觸摸一下。

我的2美分

來源

2013-04-17 08:10:24 prosailor

在持續集成中處理多個分支

回答

相關問題