构建质量

Question

我们有3个分支{开发，测试，发布}，并将为每个分支设置持续集成。我们希望能够为每个分支分配构建质量，即开发 - 准备测试...

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

我们正在使用TFS 2008，我们知道它具有内置的构建质量。它正是何时应用质量以及人们使用什么样的素质才是我们正在寻找的。

感谢

:)

Answer 1

您的目标是在每个分支中获得最高质量的可能性，并平衡验证质量水平的负担。

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

• 恢复是很难比预期。当一个分支严重破裂时，你不知道它是如何破碎的。这是因为每个问题都隐藏了他人。在任何问题上取得进展都很困难，因为你会遇到其他问题。

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

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

如果您很好地进行了测试驱动开发，那么您将最终获得一整套极其快速，可靠的单元测试。由于这些特质，您可以合理地要求开发人员在签入之前运行它们，并在每个分支中定期运行它们，并要求它们始终通过100％。您也可以随时进行重构，这可以让您在项目的整个生命周期内保持高速度。同样，如果您编写自动化集成/客户测试的好，那么它们运行迅速且可靠，那么您可以要求它们也经常运行，并且始终通过。另一方面，如果你的自动化测试是片状的，如果它们运行缓慢，或者如果你经常以“已知故障”进行操作，那么你将不得不放弃人们必须经常运行它们的频率，我会花大量时间解决这些问题。它很烂。不要去那里。

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

Answer 2

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

1. 如果您设置自动回归测试，那么所有这些测试应通过。
2. 开发人员应该使用新安装在官方和干净的测试平台上的官方开发版本进行集成测试，并给出他们的个人盖章。

当这两个条目满足特定开发版本时，您可以合理确定将此构建推广到测试不会浪费您的QA团队的时间。