实现“持续”交付的技巧

Question

一个团队在频繁发布软件时遇到了困难(每周一次)。下面是一个典型的发布时间表：

在迭代过程中：

• 开发人员在短时间(这是热情地执行)基于主分支的特性分支上处理积压的故事。
• 开发人员经常将他们的特性分支拉到集成分支中，集成分支是自动构建和测试的(就测试覆盖范围而言)。
• 测试人员有能力将集成自动部署到一个暂存环境，并且每周发生多次这种情况，从而能够持续地运行他们的测试套件。

每个星期一：

• 有一个发布计划会议来确定哪些故事是“已知的好的”(基于测试人员的工作)，因此将出现在版本中。如果故事中存在已知的问题，源分支就会退出集成。
• 没有新的代码(只有测试人员所要求的bug修复)可能会在这个星期一被引入到集成中，以确保测试人员有一个稳定的代码库来减少发行版。

每个星期二：

• 测试人员已经对集成分支进行了尽可能多的测试，给出了可用的时间，并且没有已知的bug，因此一个发行版被削减并缓慢地推到生产节点上。

这在实践中听起来不错，但我们发现要做到这一点是非常困难的。小组发现了以下症状

• 在生产中发现“微妙”的bug，而这些bug在暂存环境中没有被识别出来。
• 最后一分钟热度持续到周二。
• 生产环境上的问题需要回滚，这阻碍了持续开发，直到成功的现场部署和主分支可以被更新(因此分支从)。

我认为测试覆盖范围、代码质量、快速回归测试的能力、最后一刻的更改和环境差异在这里起着作用。有人能就如何最好地实现“持续”交付提供任何建议吗？

Answer 1

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

时间表太紧了。

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

您可以通过引入对编程和/或代码评审来提高代码质量，尽管这占用了更多宝贵的时间。

更好地估计用户故事点还可以通过隐式限制进入单个版本的用户故事，从而降低风险比率的分母，从而有所帮助。

总的来说，听起来您已经有了良好的实践，并且您有一个很好的系统来处理您的极端发布周期。你似乎走在正确的道路上。

Answer 2

为什么不使用实际的连续部署，其中提交(或推送)导致测试运行，如果测试通过，部署就会发生？

然后，如果您不确定某个更改，您可以在一个单独的分支上进行更改，这仍然会导致测试运行，但不会进行部署。

我认为试图让一个坏掉的躯干/主人保持稳定的压力比保持它稳定的压力更大。