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

Question

我在检查之前虔诚地浏览了所有代码并对代码进行了前后代码的差异并仔细阅读并确保我对这些修改进行了修改。通常我最终必须添加注释，修改变量名称，修改算法，修改代码，重新测试事物，与其他开发人员讨论他们的代码，添加新的错误/问题，但我很少立即完成签入。

然而，我注意到很多开发人员似乎都在检查他们的代码，并认为当构建中断它足够时，他们会回过头来看看他们的变化。这是我绝对不喜欢的连续构建系统之一，有时我认为开发人员不再考虑他们的代码了。

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

Answer 1

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

Answer 2

  然而，我注意到很多开发人员似乎都在查看他们的代码，并认为当构建破坏它已经足够时，他们会回过头来看看他们的变化。

在我看来，使用持续构建进行“验证”的目的确实是一种不好的做法，开发人员应该始终尝试不提交可能影响团队并中断工作的错误代码（原因）是如此明显，如果你没有得到它，只需寻找另一份工作）。因此，如果您的CI引擎未提供预测试提交（例如TeamCity，Team Foundation Server正如我刚看到的那样，可能有一天Hudson等等） ，在提交之前，你应该始终在本地同步/构建/同步（并在必要时重建）。不这样做是懒惰而不尊重团队。

  

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

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

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