我们有 3 个分支 {Dev,Test,Release} 并将为每个分支设置持续集成。我们希望能够为每个分支分配构建质量，即 Dev - Ready for test...
有没有人有这方面的经验可以提供任何建议/最佳实践方法？
我们正在使用 TFS 2008，并且我们知道它内置了 Build Qualities。这只是何时应用质量以及人们使用什么样的质量才是我们正在寻找的。
谢谢
:)
问问题
454 次
2 回答
1
您的目标是在每个分支中获得尽可能高的质量，与验证该质量水平的负担相平衡。
允许任何分支的质量下降总是有害的。不要以为你可以让 Dev 分支下地狱，然后在合并之前修复它。效果不好，原因有二：
恢复比你想象的要难。当一个分支被严重破坏时，你不知道它到底有多坏。那是因为每个问题都隐藏了其他问题。在任何问题上也很难取得任何进展，因为您会在此过程中遇到其他问题。
让质量下降没有任何好处。人们有时会说“质量、成本、进度——选择任何 2”或类似的东西。这里的错误假设是您通过允许质量下滑来“节省”。问题是，一旦质量下降，“速度”（完成工作的速度）也会下降。好消息是保持高质量并不需要额外的成本，每个人都喜欢使用高质量的代码库。
您必须做出的妥协在于您花费了多少时间来验证质量。
如果你把测试驱动开发做得很好，你最终会得到一整套极其快速、可靠的单元测试。由于这些品质，您可以合理地要求开发人员在签入之前运行它们，并在每个分支中定期运行它们，并要求它们始终 100% 通过。您还可以随时进行重构，这使您可以在项目的整个生命周期内保持较高的速度。
类似地，如果您编写好自动化集成/客户测试，以便它们快速可靠地运行，那么您可以要求它们也经常运行并始终通过。
另一方面，如果您的自动化测试不稳定，如果它们运行缓慢，或者如果您经常以“已知故障”运行，那么您将不得不放弃人们必须运行它们的频率，并且您将花费很多解决这些问题的时间。糟透了。不要去那里。
最坏的情况是，您的大多数测试都不是自动化的。你不能经常运行它们，因为人们在这些事情上真的很慢。您的非发布分支质量将受到影响，合并速度和开发速度也会受到影响。
于 2009-08-06T04:26:53.023 回答
0
以确定性和可重复的方式评估构建的质量绝对具有挑战性。我建议如下：
- 如果您准备进行自动回归测试，那么所有这些测试都应该通过。
- 开发人员应该使用新安装在官方和干净的测试平台上的官方 Dev 版本来集成测试他们的每个更改，并给予他们个人的批准印章。
当特定 Dev 构建满足这两个项目时，您可以合理地确定将此构建提升到 Test 不会浪费您的 QA 团队的时间。
于 2009-07-09T14:15:11.507 回答