提交后策略详情

提交后测试失败意味着代码中存在错误。错误存在的时间越长，由于持续的代码贡献，修复起来就越难。因此，我们希望快速修复错误。Beam 社区的提交后测试策略有助于保持我们的代码和测试结果处于良好状态。

先回滚

Beam 使用“先回滚”方法：解决测试失败的第一步是回滚导致问题的代码更改。这种方法的两个主要优点是实施时间短和可靠性高。当我们先回滚时，我们很快就会恢复到之前验证过的良好状态。

从高层次来看，这种方法包括以下步骤

1. 还原导致问题的提交。
2. 重新运行提交后测试以验证测试通过。
3. 推送还原提交。

有关此策略的背景信息，请参阅 邮件列表线程 和 设计文档。

测试失败是一个关键/P1 问题

很难正确验证在有错误的代码基础上进行的新更改。在某些情况下，添加更多代码可能会使问题更严重。为了避免这种情况，修复失败的测试是我们的最高优先级。

不稳定的测试是一个关键/P1 问题

不稳定的测试被视为失败的测试，修复不稳定的测试是一个关键/P1 问题。

不稳定的测试是指使用相同代码版本时随机成功或失败的测试。不稳定的测试失败是最危险的失败类型之一，因为它们很容易被忽略——不稳定测试的另一次运行可能会成功通过。但是，这些故障可能会隐藏真正的错误，而且不稳定的测试通常会慢慢累积。有人必须反复对故障进行分类，而且不稳定的测试通常是最难修复的测试。

不稳定的测试不会提供可靠的质量信号，因此快速修复不稳定性非常重要。如果修复需要一段时间才能实施，最好在修复就绪之前禁用测试。

Martin Fowler 有一篇关于测试中非确定性的好文章 文章。

不稳定的测试必须修复或移除

不稳定的测试不会提供可靠的质量信号，这会对所有测试产生不利影响，并会导致对我们的测试套件失去信任。结果，贡献者可能会开始忽略测试失败。

我们希望每个人都信任我们的测试，因此必须努力修复所有不稳定的测试。如果无法修复不稳定的测试，我们必须移除该测试。

将新的提交前测试作为提交后修复的一部分添加

提交后测试是一个重要的安全措施，但我们希望快速失败。快速失败意味着我们希望在提交前测试中检测到错误，而不是在提交后测试中检测到错误。

当您实现提交后测试失败的修复程序时，添加一个新的提交前测试，该测试将检测将来类似的失败。例如，您可以实现一个新的单元测试，涵盖有问题的代码分支。

如果 Beam 影响下游项目，请告知社区

有多个外部项目依赖于 Beam，这些项目包含 Beam 存储库之外的测试。例如，Dataflow、Samza 运行器和 IBM Streams。

当一个外部项目遇到由 Beam 中的（PR）引起的错误，并且因此要求对 Beam 存储库进行更改时，首先要创建一个 GitHub 问题，解决以下三个问题

1. 关于问题是什么的描述。
2. 回滚是否可以解决它？（或者它应该以其他方式修复）
3. 回滚是解决问题最好的方法吗？

鼓励将讨论也带到开发人员邮件列表中。理想情况下，在事件发生后，我们更希望就是否应该扩展 Beam 存储库中的测试进行讨论，目标是在未来尽早捕获类似问题。