如何确保连续构建系统的质量检查？

Question

我在检查前仔细检查了所有的代码，并对代码前后进行了区分，并仔细阅读了代码，并确保了解其中的变化。通常，我最终不得不添加注释，修改变量名称，修改算法，修改代码，重新测试，与其他开发人员讨论他们的代码，添加新的错误/问题，但我很少会立即执行签入操作。

但我注意到，不过现在很多开发人员似乎都在检查他们的代码，并认为当构建打破了它就足够了，然后他们回去看看他们的变化。这是关于连续构建系统的事情之一，我绝对不喜欢它，因为有时我认为开发人员不再考虑他们的代码。

哪些最佳实践是有保证只有高质量的代码进入持续构建系统？

Answer 1

但是我注意到，现在很多开发人员似乎都在检查他们的代码，并认为当构建打破了它已经足够的时候，他们回去看看他们的变化。

在我看来，使用持续构建的“验证”的目的确实是一个不好的做法，开发人员应始终尽量不要犯坏的代码，它可以影响到球队和中断的工作（的原因是如此很显然，如果你没有得到那个，就找另一份工作）。因此，如果您的CI引擎不提供预测试提交（如我刚刚看到的TeamCity,Team Foundation Server，可能有一天Hudson等），您应该始终在本地同步/建立/同步（并在必要时重建）承诺。不这样做是懒惰，不尊重团队。

有什么最佳实践可以确保只有质量代码进入连续构建系统？

• 以防万一，提醒为什么破坏构建不好：糟糕的代码可能会影响整个团队和中断的工作（叹气）。
• 如果您可以获得工具支持（请参阅上面提到的解决方案），请取得它。
• 如果不是，请记录正确的工作流程：1.同步2.本地生成3.同步4.如果需要，返回2 2.提交。使其可见，以便没有任何借口。
• 如果这是一个选项，使用类似（或类似）的Hudson's Continuous Integration Game plugin。这可以让事情变得更有趣。

我见过有人使用轻微的金钱“惩罚”破碎的构建，但我不太喜欢这个想法。首先，我们应该能够像负责任的成年人一样行事。其次，获得的结果是人们开始拖延提交（最终与预期收益相反）。

Answer 2

Team Foundation Server有一些名为pre checkin validation的东西。