发布分支策略

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版本就会发布，它们也需要在那里进行回归测试。因为基本上你需要一个在你的应用程序中支持所有模块的支持组合的矩阵，每个模块都需要一定程度的回归/质量保证测试。这是一只熊，在那里，失败了。

从版本控制的角度来看，我建议为每个模块分开存储库，以便每个可以分支/标记/等。在任何其他模块的独立点上。这就是您的兼容性矩阵，将它们结合在一起。