颠覆、持续集成和 Scrum [关闭]答案

【问题标题】：Subversion, Continuous Integration, and Scrum [closed]颠覆、持续集成和 Scrum [关闭]
【发布时间】：2014-08-28 16:21:05
【问题描述】：

我们如何设置 Subversion 策略，以便我们可以轻松地“退出”整个故事的更改，同时保持持续集成？

在我的工作场所，我们正在让 Scrum 进入我们之前没有流程/“牛仔编码”的领域。这很有趣（矮人要塞的定义），但不是这个问题的重点。

在 Scrum 中，我们有可能让产品负责人有权对故事的完成说“不”，或者在 sprint 中可能没有“完成”故事的工作。这个想法是，如果某事没有“完成”，它就不会被部署。内部存在分歧 - 一些人说我们应该部署一半完成的东西“捆绑”所以它不能被使用，但我强烈不同意（这完全是另一个话题）。

通过持续集成，鼓励开发人员经常承诺及早发现集成/回归问题。对我们来说，这意味着颠覆提交，主要是发布分支模式，尽管这是灵活的。

如果我们不断地提交到任何分支，将其称为 sprint 分支，那么当我们（很少！）到 sprint 结束并且有一个无法部署的故事时会发生什么？我需要从部署分支“取消合并”支持该故事的任何更改。是否有一个分支策略/提交策略使这相对可行，无需大规模手动交互？我应该担心吗？

【问题讨论】：

我投票决定将此问题作为题外话结束，因为project management is now off-topic on Stack Overflow。请在 SoftwareEngineering.SE 和 ProjectManagement.SE 上提出这些问题。（不幸的是，这个问题太老了，无法迁移。）

【解决方案1】：

我认为没有任何简单的解决方案。一旦您“取消合并/撤消”您的更改，这可能很困难，您必须重新测试所有内容。如果您最终有一个无法投入生产的分支，一个更好的策略是部署一个已经准备好的旧版本。然后，一旦准备好，就可以部署新分支。

【讨论】：

这将是使用 CI 进行的预 QA，因此测试将在很大程度上自动重新运行。另外，我为什么要为一个破碎的故事延迟整个 sprint 的“完成”工作？
如果是 pre-QA，那么我认为您希望每个故事都有一个分支。一旦故事通过 CI，您将其合并到主分支中。如果您遇到 QA 在发布前发现问题的情况，您要么必须将故事拉出并重新测试，要么推迟发布直到您修复它。
@Dave 我在考虑类似的思路，但每个故事的一个分支似乎可能导致合并/集成地狱，违背 CI 的目的。
@ThisSuitIsBlackNot，我同意如果您的故事非常小，它可能会导致大量合并。我们经常这样做，除非您有几个人在同一代码区域工作，特别是如果您使用好的合并工具，否则这很好。这样做的另一个好处是你的所有提交都在分支上，因此更容易进行代码审查。