问构建质量

EN

您的目标是在每个分支中获得尽可能高的质量，平衡验证该质量级别的负担。

在任何分支中允许质量下降总是有害的。不要认为你可以让Dev分支下地狱，然后在合并之前修复它。它不能很好地工作，有两个原因：

• Recovering比你想象的要难，。当一个分支被严重折断时，你不知道它到底有多坏。这是因为每个问题都隐藏了其他问题。这也很难在任何问题上取得任何进展，因为你会在way.
• Letting质量下降的过程中遇到其他问题，这不会为你节省任何。人们有时会说“质量，成本，进度-选择任何2个”或类似的东西。这里的错误假设是，你通过允许质量下降来“节省”。问题是，一旦质量下降，“速度”也会下降--你完成工作的速度。好消息是，保持高质量实际上并不需要额外的成本，每个人都喜欢使用高质量的代码库。

你必须做出的妥协是你花了多少时间来验证质量。

如果你做好了测试驱动开发，你将会得到一套非常快速、可靠的全面的单元测试。由于这些特性，您可以合理地要求开发人员在签入之前运行它们，并在每个分支中定期运行它们，并要求它们始终100%通过。您还可以在进行重构的过程中保持重构，这使您可以在整个项目生命周期中保持高速度。

类似地，如果您编写的自动化集成/客户测试很好，那么它们可以快速可靠地运行，那么您可以要求它们也经常运行，并且总是通过。

另一方面，如果您的自动化测试不稳定，如果它们运行缓慢，或者如果您经常操作“已知故障”，那么您将不得不放弃人们必须运行它们的频率，并且您将花费大量时间来解决这些问题。真没意思。别去那儿。

最坏的情况是，您的大多数测试都不是自动化的。你不能经常运行它们，因为人们在这些事情上真的很慢。你的非发布分支质量将受到影响，合并速度和开发速度也会受到影响。

以确定性和可重复性的方式评估构建的质量肯定是具有挑战性的。我的建议如下：

pass.

• Developers

1. 如果你准备做自动化回归测试，那么所有这些测试都应该使用新安装在官方干净的测试平台上的官方开发人员版本来集成测试他们的每个更改，并给出他们的个人批准戳。

当这两个项目满足特定的开发人员构建时，您可以合理地确定，将此构建提升到测试将不会浪费您的QA团队的时间。