如何確保連續構建系統的質量檢查？

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的東西。