發佈分支策略

Question

我們的應用程序是一種使用Drools的基於規則引擎的應用程序。它具有核心框架邏輯，客戶特定的業務邏輯將作爲規則進行部署。

特定版本將包含多個功能。例如，Feature_Branch_Toyota_1.0,Feature_Branch_Honda_1.0等，將以相同版本Rel_1.0及其通過的QA測試。最後一分鐘由於時間限制或更改的複雜性，業務沒有時間進行UAT（用戶驗收測試）Feature_Branch_Honda_1.0更改。

現在企業想推遲Feature_Branch_Honda_1.0更改下月發佈，但仍然Feature_Branch_Toyota_1.0變化應該去爲它安排在Rel_1.0。

如果我們去掉Feature_Branch_Honda_1.0變化出來的Rel_1.0則QA會問的迴歸測試，這將影響到實際的發佈計劃。有沒有辦法避免這種情況？或者是否有任何模式將每個功能部件作爲同一個發行版分支中的獨立組件，以便如果任何功能被推遲到下一個發行版，則不會影響當前發行版中的其他功能。

建議/意見將不勝感激。

Answer 1

看起來質量保證完全在他們要求迴歸測試的權利範圍內。

原文：本田1.0 + 1.0豐田==>相對1.0 現在：豐田1.0 ==>相對1.0

QA現在需要確保豐田1.0有沒有什麼inadvertely取決於本田1.0，似乎可能某些相互依賴性會導致一些比預期更緊密的耦合結果。所以肯定需要進行某種測試。然後在本田1.0版本發佈之後，豐田1.1版本就會發布，它們也需要在那裏進行迴歸測試。因爲基本上你需要一個在你的應用程序中支持所有模塊的支持組合的矩陣，每個模塊都需要一定程度的迴歸/質量保證測試。這是一隻熊，在那裏，失敗了。

從版本控制的角度來看，我建議爲每個模塊分開存儲庫，以便每個可以分支/標記/等。在任何其他模塊的獨立點上。這就是您的兼容性矩陣，將它們結合在一起。