我们如何每隔一周在生产版本中仅包含准备发布的功能？

我是一个相当大的敏捷团队的软件开发人员（我们有8个开发人员积极地对单个代码存储库进行更改）。每隔两周，我们会将软件的新版本投入生产。这是我们当前的工作流程：

• 在开始新任务时，开发人员在主开发分支（我们使用git）的基础上创建一个“功能分支”，并在此新分支上工作
• 开发人员完成任务后，将其功能分支合并回开发分支
• 开发人员将开发分支合并到质量检查分支。
• 质量检查分支会触发构建。此构建的输出已部署到我们的QA环境中，以允许测试人员开始其测试。

对于我们的测试人员来说，发现这些已合并到QA分支中的新功能的问题很常见。这意味着在任何给定的时间，QA环境都可能包含一些新功能-一些经过测试且没有错误，还有一些已损坏。这使得发布变得困难，因为很少有QA版本处于生产就绪状态。

为了减轻这种情况，我们一直试图启动“质量检查冻结”，这意味着开发人员在发布前几天不会将我们的开发分支合并到质量检查分支中。质量检查环境的错误修复程序直接在质量检查分支中进行，并合并到开发分支中。从理论上讲，这使新的，已损坏的功能无法进入质量检查，同时仍使我们能够解决质量检查中已有的问题。

虽然“质量检查冻结”的概念已部分成功，但很难进行协调，人们常常对是否允许其合并到质量检查中感到困惑。设置“ QA冻结”截止日期也很困难-每个人都喜欢在冻结和发布之间留出一些喘息的想法，但是实际上，他们宁愿在下一个发行版中发挥自己的功能，也不愿遵守截止日期。

是否有更好的方法来确保我们每两周发布一次新版本？

周围有一些问题正在引起您遇到的问题。

第一个是长期运行的质量检查分支。拥有与开发主线平行的长期运行的分支可能会引起混乱，因为QA分支和主线都需要重复不同的工作。这意味着您正在检入需要合并到主线的QA分支的修补程序（这不是一件坏事），或者正在检入已合并到QA分支的主线（可能的错误来源） 。

长期运行的并行分支的另一个问题是文件可能永久不同步。永远不会合并的代码修复，或者从未经过测试的生产版本所需的配置，并且是开发主线的一部分。

接下来，您将遇到角色冲突。这意味着包装角色（稍后会详细介绍）没有得到足够的隔离。

在git-flow模型中，发布分支从开发分支（不是将开发合并到QA），并且所有修复都被检入发布分支，然后合并回到开发分支。

可以在Advanced SCM Branching Strategies（高级SCM分支策略）中找到一些分支哲学（我认为是一本不错的书）。这着重于每个分支机构可能扮演的角色。发行分支承担打包角色。

包装角色经常与积累角色（或更常见的是主线角色）混淆。一旦完成了预期的开发和维护并完成了所有积累，就可以准备发布代码了。这样的努力可能不是一件容易的事，需要一个发布工程师团队和除已执行之外的其他修复程序。包装部门的政策与维护部门的政策明显不同，正如包装角色所暗示的那样，仅应解决使产品可发布的必要更改。

• 从开发点分支到发布分支。QA从其构建的发行分支只有一个分支，而没有从开发合并。
  • 如果您要走那条路，使用一致的命名和钩子，则可以防止将合并完成到发布分支中。
• 修复发布分支中需要修复的所有内容，并将这些更改合并回主线。
• 在发布工作结束时，将release分支合并到“ releases go here”分支中，并对其进行标记。
  • 某些网站没有“发布到这里”分支，而只是在发布分支的末尾悬吊有一个标签。

人们应该认真考虑将整个git-flow应用到位。这与目前正在做的事情相差不远，并且在每个分支的含义以及每个分支与其他分支的交互方式方面都施加了一定的纪律和一致性。

对我来说，问题似乎在于您只有一个质量检查分支。

对于每个发行版，请与主要开发主干/母版分开创建一个QA分支。然后，仅合并该分支功能的bug修复程序-不再合并新功能。对该分支进行质量检查。

这样，“冻结”就很明显了-它在分支名称中。您可以使用类似我不知道的东西release/26/10/2015。显然，此后没有人应该合并新功能。

如果您甚至在冻结之前都不叉该分支，这将特别有用。人们可以随时合并以掌握，如果不及时进行测试，它将不会成为该版本的一部分。

没有一个长期运行的质量检查分支，这只是在乞求麻烦。从主开发分支派生每个发行版并对该分支进行质量检查。

您已映射到如下所示的Development-MAIN-Production分支模型。MAIN上方的区域被称为开发区域。MAIN以下的区域是生产区域。

我认为与您相关的此模型的要点：

• 您的开发人员需要频繁（每周2-3次）前向集成（FI）（FI =从MAIN合并）进入其DEV分支，以确保他们的最新更改始终考虑最新的总体发展情况。
• 您的开发人员只有在达到了要向QA公开的功能完善里程碑并准备在其中提供快速修复的功能完成里程碑时，才需要在TEST分支中进行反向集成（RI）（RI =向MAIN合并）。对质量检查反馈的回应。修补程序将在TEST分支上执行，并立即在其DEV分支中执行FI。
• 从不从任何DEV分支到主节点的RI
• 当您的质量检查人员认为测试的质量还可以时，始终将RI从TEST分支分支到MAIN。保持合并到MAIN的高质量阈值。至少，您的产品经理必须能够始终根据MAIN中的最新提交来演示产品的工作版本。
• 仅在需要时在生产区域中创建分支。您的构建服务器应始终标记所有分支，包括来自开发区域的分支，并且任何构建/发行版的源都应始终可识别，无论其来自何分支。
• 仅从MAIN或生产区域获取发布的生产版本。如果以后需要提供确切发布版本的修复程序（即，您不能只提供MAIN的最新版本），请在需要修复时从错误发行版的MAIN标记在生产区域中创建分支。始终在HotFix分支上解决问题，然后立即将RI变成MAIN，将FI变成TEST。

我怀疑您有问题，因为：

• 您的开发人员将RI转换为功能里程碑尚未完成的TEST代码
• 您的开发人员RI进入了TEST，而没有获得QA的批准（即QA无法控制注入TEST的内容）
• 当质量检查人员报告有关TEST的错误时，您的开发人员会在其DEV分支上对其进行修复，然后将其RI插入TEST。这是一个主要的坏习惯，因为合并总是会带来其他不完整的开发废话。他们应该始终在TEST上修复它，然后将FI插入他们的DEV分支。如果不能在TEST上修复，那么他们首先会提供全部废话，您会遇到更大的问题。
• 您的开发人员从TEST获得FI的频率不高，因此一旦交付TEST，他们就会破坏TEST的稳定性。平衡将FI发送到DEV的频率是一种很好的方法。推迟太多时间，这将在交付前带来极高的成本和风险，这是您永远都不需要的。经常这样做，如果同时与TEST中其他人交付的工作重叠太多，则您将无法完成任何实际的开发工作。

据我了解的问题，您有两个问题。（a）损坏的功能正在与您要发布的良好功能合并；（b）您希望在保留损坏的功能的同时释放良好的功能。作为对可能解决方案的限制，我假设您希望最终/官方的质量检查测试在一个集成分支中进行，该分支包含计划用于下一版本的所有功能。

无论您采用哪种SCM分支模型，建议您尝试以下一种或两种方法：

1. 向每个功能团队分配质量检查资源。让他们对来自功能分支的构建进行一些功能测试，并赋予他们决定何时可以合并某个功能的权限。理想情况下，让他们与功能团队（其余）协作，以便在编写内容后立即对其进行测试。（请注意，这并不意味着他们必须自己进行所有测试。）
2. 使用功能切换，而不是功能分支或除功能分支之外。正确执行功能切换后，您可以关闭已损坏的功能，而无需尝试将其与代码取消合并，因此您可以测试并释放其他功能。客户无法访问我正在谈论的那种切换；您不希望测试数量呈指数增长的组合。您可以在“质量检查”分支上设置切换，以匹配您计划发布的功能，如果计划因某个功能尚未就绪而发生更改，则可以更改该切换。

我看到一个非常简单的解决方案是在一个比您大的团队中工作，那就是让每个人都在一个分支机构工作和部署。

您说团队是敏捷的，但尚不清楚您是使用冲刺（即Scrum）还是更连续的流程（即看板）方法。假设您正在执行冲刺，则团队的目的是在每个冲刺结束时发布代码，以供每两周发布一次。由于所有功能都是一起开发的，因此不会混淆一个功能是否会破坏另一个功能。由于开发人员交付给他们的开销较低，因此测试人员可以访问较小的功能块。而且，您实际上并不需要QA冻结，而是每个人都知道sprint何时结束，并且不应该进行无法完成的工作，或者处于可部署（即禁用）状态。

显然，任何方法都各有利弊，我将其作为一种选择，不一定是“最佳方法”。

之所以会出现这些问题，是因为您发布到QA的代码质量不够好（而且有人吗？！），因此您需要开始更好地发布到QA，这样他们就不必如此频繁地收到bigfix。最简单的方法是引入您发布到的中间分支（称为测试）。这仍然处于开发职责范围之内，但是它允许开发人员推动它继续工作，同时还具有一个集成分支，该分支的质量应足以发送给QA。

可以在此分支上进行集成测试，以便找到QA当前正在发现的错误，可以将错误修复在原始分支上，然后再次合并，然后再次进行，直到可以在该分支上直接修复错误或错误为止（我建议前任的）。通过一系列基本测试后，就可以将其发送给质量检查人员，以检查“用户黏手指和手指干什么？”。测试。

因此，此方法旨在保护QA分支免受破坏的开发功能的影响-不管是因为该功能的代码编写得不够好，还是是否存在意外的集成问题都无关紧要。只有通过集成测试的dev分支才能晋升为QA。