我的团队目前正在进行开发时使用功能分支。对于sprint中的每个用户故事，我们创建一个分支并单独处理它。因此，根据Martin Fowler的说法，我们实行持续建设，而不是持续整合。
我有兴趣推广类似于Debian的不稳定/测试/稳定方案，以便从unstable =＆gt;提升代码。 testing =＆gt;稳定。
我建议，我们对已完成的定义是
一旦被PO接受，故事将被合并到测试分支中。我们的测试开发人员将大部分时间花在了这个分支上，并且不断运行我们的自动化测试。
然而，这让我很害怕，因为来自另一个不完整故事的提交现在可能会进入测试分支。也许我错过了一些东西，因为这似乎是一个不受欢迎的结果。那么，如果转向代码促销策略来解决我们的功能分支问题，您建议采用什么策略/指南？感谢。
更新：Fowler讨论功能切换（http://martinfowler.com/bliki/FeatureToggle.html）
答案 0 :(得分：0)
我认为你可能会遗漏某些东西，或者要求逻辑上的不可靠性。从功能上讲，有两种方法可以实现从“不稳定”到“测试”的合并。您可以合并仅与给定“完成”故事相关联的代码，或者您可以在故事完成时将所有从不稳定合并到测试中。
这些优点和缺点。第一个优点是，事情只有在测试分支完成时才会出现在测试分支上，所以你不会有不稳定的部分不完整的故事。缺点是您合并的部分可能取决于您未合并的部分，因此合并不仅仅是一个简单的副本。或者，第二个优点是合并是微不足道的（只是副本，不需要考虑），但是在测试中你最终会得到不完整的东西。
从功能上讲，在某些方面，第一个选项就像拥有不同的功能分支，除非它们都在同一个树中。您仍然必须有一些方法来跟踪哪些代码是“故事”的一部分，并且您必须解开各个部分以便将其中的某些特定部分合并到测试中，并且您存在相互依赖性的问题，等等解开的结果。因此，这种合并策略实际上可能无法为您带来持续集成的许多好处 - 但是，在某些情况下，它可能是一个很好的权衡，并保留对您的项目更有价值的持续构建的一些好处。
另一方面，听起来像持续集成的一个公平部分是，事物不断被整合到主干中，而不是仅仅在它们“完整”时被集成。因此，如果你完全接受这种哲学，在我看来，在你的测试分支中有不完整的东西是预期的情况 - 它是系统哲学中固有的。
值得注意的是，Debian等人在功能上遵循第一种方法;当事物在某种程度上完成时，事物只会以零碎的方式从一个阶段合并到另一个阶段。在某种程度上，只需将代码纠缠在一起的“故事”合并在一起，就可以简化事情，但是为了将事物从一个级别合并到另一个级别，“backporting”补丁有很多工作要做。尽管拥有三级不稳定/测试/稳定结构的想法似乎对持续集成很有用，但如果你使用merge-everything哲学，我认为除此之外的Debian政策也不会过多。
答案 1 :(得分：0)
你不必过于懂得马丁的话。不同的方法可能适用于不同的情况
答案 2 :(得分：0)