打造品质

Question

我们有 3 个分支 {Dev,Test,Release} 并且将为每个分支设置持续集成。我们希望能够为每个分支分配构建质量，即 Dev - Ready for test...

有没有人有这方面的经验可以提供任何建议/最佳实践方法？

我们正在使用 TFS 2008，并且我们知道它内置了 Build Qualities。它只是何时应用质量，人们使用什么样的质量是我们正在寻找的。​​p>

谢谢

:)

Answer 1

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

允许质量下降到 any 分支总是有害的。不要以为你可以让 Dev 分支下地狱，然后在合并之前修复它。效果不好，有两个原因：

• 恢复比您想象的更难。当一个分支被严重破坏时，你不知道它到底有多坏。那是因为每个问题都隐藏了其他问题。也很难在任何问题上取得任何进展，因为您会在此过程中遇到其他问题。

• 让质量下降无济于事。人们有时会说“质量、成本、进度——选择任何 2”或类似的东西。这里的错误假设是您通过允许质量下滑来“节省”。问题是，一旦质量下降，“速度”（完成工作的速度）也会下降。好消息是，保持高质量并不需要额外花费，每个人都喜欢使用高质量的代码库。

您必须做出的妥协在于您花费了多少时间验证质量。

如果您很好地进行测试驱动开发，您最终将获得一整套极其快速、可靠的单元测试。由于这些品质，您可以合理地要求开发人员在签入之前运行它们，并在每个分支中定期运行它们，并要求它们始终 100% 通过。您还可以随时进行重构，这样您就可以在项目的整个生命周期内保持较高的速度。

同样，如果您编写好自动化集成/客户测试，以便它们快速可靠地运行，那么您可以要求它们也经常运行并始终通过。

另一方面，如果您的自动化测试不稳定，如果它们运行缓慢，或者如果您经常以“已知故障”运行，那么您将不得不放弃人们必须运行它们的频率，并且您将花大量时间解决这些问题。糟透了。不要去那里。

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

Answer 2

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

1. 如果您准备进行自动回归测试，那么所有这些测试都应该通过。
2. 开发人员应使用新安装在官方且干净的测试平台上的官方开发版本对他们的每项更改进行集成测试，并给予他们个人的批准印章。

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