实现“持续”交付的提示

一个团队经常（每周一次）遇到发布软件的困难。以下是典型的发布时间表：

在迭代过程中：

• 开发人员在基于master分支的短时（强烈执行）功能分支的待办事项上处理故事。
• 开发人员经常将其功能分支拉入集成分支，该集成分支会自动不断构建和测试（就测试覆盖范围而言）。
• 测试人员可以自动将其集成到暂存环境中，并且每周进行多次，从而可以持续运行他们的测试套件。

每逢星期一：

• 有一次发布计划会议，以确定哪些故事是“已知的好”（基于测试人员的工作），因此将在发布中。如果故事存在已知问题，则将源分支从集成中撤出。
• 在本周一，不得将任何新代码（仅测试人员要求的错误修复）用于集成，以确保测试人员具有稳定的代码库来减少发布。

每逢星期二：

• 测试人员已经在可能的时间范围内尽可能多地测试了集成分支，并且没有已知的错误，因此将发行版剪切并缓慢地推送到生产节点。

在实践中这听起来不错，但是我们发现很难实现。小组看到以下症状

• 在生产环境中发现了在过渡环境中未发现的“细微”错误。
• 最后一分钟的热修复程序一直持续到星期二。
• 生产环境中的问题需要回滚，这会阻止继续开发，直到成功完成实时部署并且可以更新master分支（并由此分支）为止。

我认为测试覆盖范围，代码质量，快速回归测试的能力，最新更改和环境差异都在这里发挥作用。谁能提供有关如何最好地实现“连续”交付的任何建议？

• 在生产环境中发现了在阶段环境中未发现的“细微”错误 -在其中一个存在此类问题的项目中，我已经看到可以通过称为双重问题的策略非常成功地解决了这一问题。我的意思是，对于那样的错误，人们在问题跟踪器中创建了两张票证：一张分配给开发人员以修复代码，另一张分配给测试人员以设计和建立回归测试或临时环境的更改，以防止将来重复。这有助于使分期保持足够接近以生产。

• 生产环境中的问题需要回滚 -如果这些回滚很频繁，则您的每周发行实际上是假的-请考虑将频率调整到真正有效的水平。通过假冒我的意思是，如果你的两个每周发布的发言权一个卷回这意味着用户在两周内面临新的（工作）发布一次-这是所有罪状，没有的时候，你部署的数量。

• 热情地执行了功能分支 -这是否意味着在一段时间之前，您还尝试过使用单个分支，却发现它的质量较差？如果是，则跳过其余部分。否则，请尝试在单个分支上工作（如果需要，请在google中获取分支策略“开发分支”或分支策略“不稳定主干”的详细信息）。或者，如果您使用Perforce，请在Web上搜索有关分支和合并的Microsoft准则。我试过这样说吗？抱歉，应该测试适当的单词：我的意思是，1）计划何时以及如何衡量单个分支是否比现在的分支更好，以及2）计划何时以及如何切换回功能分支，以防万一测试失败。

PS。

通过在网上搜索诸如软件项目风险管理之类的内容，您可能会找到更多类似的技巧。

更新

<来自评论的副本>

我认为频繁的热修复是测试管道损坏的症状-不是这种情况吗？无论哪种方式，他们都需要重复发布才能获得最新补丁，从而使运维团队付出更多工作。此外，热修复程序通常在极端的时间压力下进行编码，这意味着它们的质量可能会比正常工作低。

</从评论中复制>

• 最后一分钟的热修复程序 -对于我来说，上述关注点以及您对损坏的测试管道的引用对我来说都是合理的。通过此更新，您先前的通知（周一阻止新代码集成）听起来像是管道中断（我认为更确切的词会被争辩）的另一种症状。通过争用，我的意思是：您使用单个分支同时满足两个目的：集成和发布。当采用释放方式时，这两个目的开始相互冲突，推动需求冲突：集成目的最好与连续开放的分支（Merge Early And Often）配合使用，而释放稳定性则受分支密封的好处（隔离）越长越好。呵呵，看起来好像拼图零件开始匹配了...

..看起来，周一冻结似乎是为了达到冲突的目的而做出的妥协：开发人员遭受新代码集成块的困扰，而测试人员遭受这一块过于简短的痛苦，每个人都有些不满意，但或多或​​少地满足了这两个目的。

您知道，鉴于以上所述，我认为您最好的选择是尝试从专用分支中释放（而不是集成）。这个分支是像集成一样长寿，还是像您的功能分支（如“功能”发布，好了）一样短暂—取决于您，它必须是独立的。

试想一下。目前，您发现有一天不足以方便地稳定释放，对吗？使用新的分支策略，您可以在发布前2天进行分叉，而不用花1天的时间，这没问题。如果发现两天还不够，请尝试在三天前进行分叉，等等。可以的是，您可以根据需要尽早隔离发行分支，因为这将不再阻止将新代码合并到集成分支。请注意，在此模型中，根本不需要冻结集成分支-开发人员可以在星期一，星期二，星期五等任何时间连续使用它。

您为此付出的代价是修补程序的复杂化。这些将必须合并为两个分支，而不是一个分支（发行版+集成）。这是测试新模型时应关注的重点。跟踪所有相关的内容-您在合并到第二个分支上花费的额外精力，与可能忘记合并到第二个分支的风险相关的努力-所有相关的内容。

在测试结束时，只需汇总您跟踪的内容，并了解这种额外工作量是否可以接受。如果可以接受，就可以了。否则，请切换回当前模型，分析出了问题所在，然后开始思考如何进一步改进。

更新2

<来自评论的副本>

我的目标是在迭代内测试和交付故事（在配置墙的后面或前面），只有在测试人员测试迭代中执行的工作（而不是稳定前一次迭代的代码）时才能实现。

</从评论中复制>

我知道了。好吧，我没有这种方式的直接经验，但是看到在与我们相关的项目中成功完成了迭代式测试。由于我们的项目遵循的是相反的方式，因此我对这些相反的方法也进行了面对面的比较。

从我的角度来看，超出迭代的测试方法在那场比赛中看起来更胜一筹。是的，他们的项目进展顺利，测试人员比我们的测试人员更快地发现了错误，但这在某种程度上没有帮助。我们的项目也进行得很好，以某种方式，我们可以提供比他们更短的迭代，并且我们拥有比他们更少（更少）的发布版本，并且我们这边的开发人员和测试人员之间的紧张关系也更少。

顺便说一句，尽管他们身边的检测速度更快，但我们设法获得了几乎相同的平均bug寿命（寿命是引入和修复之间的时间，而不是引入和检测之间的时间）。也许我们在这里甚至有一点优势，因为迭代时间更短且发布的滑行次数更少，因此我们可以断言，平均而言，我们的修补程序比用户更快地到达用户。

总结起来，我仍然认为隔离发布代码行有更好的机会提高您的团队生产力。

再想一想...

• 隔离发布代码行的机会更大 -重新阅读后，我觉得这可能会给我留下印象，使我不鼓励您尝试进行迭代测试。我想清楚地表明我没有。

在您的情况下，迭代测试方法看起来很安全（尝试测试），因为您似乎对如何实现（平滑的测试管道）以及主要障碍有清晰的了解。毕竟，如果您发现很难正确处理该管道，则始终可以选择使用其他方法。

顺便说一句，关于障碍物，在这种情况下值得关注的其他问题将是诸如在开发人员方面无法重现错误以及在测试人员方面无法找到/迟到验证修复的问题。这些也可能会阻塞您的管道，就像现在通过修补程序发生一样。

在不了解用户故事的性质和数量的情况下，我不得不说一个1周的发布周期似乎是极端的。您所描述的上述场景是经过复杂计划的，涉及一系列不同的分支，合并点，切换，环境和测试套件，或多或少地创建了一个人为系统，在该人的系统中，由于计划的复杂性而导致的单个错误可能导致延迟发布或质量差。这可能对后续发行版产生多米诺骨牌效应。

恕我直言，日程安排太紧了。

您可以通过编写更有效的单元测试以及特定于环境的集成测试来增加代码覆盖率。

您可以通过引入配对编程和/或代码审查来提高代码质量，尽管这会浪费更多的宝贵时间。

更好地估计用户故事点还可以通过隐式限制一次发布的用户故事来帮助您，从而降低风险比率的分母。

总体而言，这听起来像您已经制定了良好的实践，并且您拥有一个可以应对极端发布周期的良好系统。您似乎走在正确的道路上。

为什么不使用实际的连续部署，在这种情况下提交（或推送）会导致测试运行，并且如果测试通过，则会发生部署？

然后，如果不确定更改，请在单独的分支上进行操作，这仍然会导致测试运行但没有部署。

我认为，要使损坏的后备箱/主控主机保持稳定，要承受的压力要更大。