建立质量

Question

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

有没有人可以提供任何建议/最佳实践方法？

我们正在使用TFS 2008，我们意识到它内置了构建质量。它正是应用质量的时候，人们使用的是什么样的品质是我们正在寻找的。

谢谢

：）

Answer 1

您的目标是在每个分支机构中获得最高质量，并与验证质量水平的负担相平衡。

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

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

• 让质量下降不会为您节省任何费用。人们有时会说“质量，成本，时间表 - 挑选任何2”或类似的东西。这里的错误假设是你通过允许质量下滑来“节省”。问题是，一旦质量下降，“速度”也会下降 - 你完成工作的速度。好消息是保持高质量并不会带来额外成本，每个人都喜欢使用高质量的代码库。

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

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

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

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

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

Answer 2

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

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

如果对于特定的Dev版本满足这两个项目，您可以合理地确定将此版本推广到测试不会浪费您的QA团队的时间。