雖然持續集成（CI）在降低項目風險方面極為有效，但是它對日常編碼活動有更多要求。在這份由兩個部分組成的持續集成反模式文章的第二部分，自動化專家兼 Continuous Integration: Improving Software Quality and Reducing Risk 一書的合著者 Paul Duvall 繼續介紹持續集成的反模式，并重點演示如何避免它們。
在這篇共兩部分的文章的 第一部分，我描述了以下六種持續集成反模式：
- 簽入不夠頻繁，這會導致集成被延遲
- 破碎的構建，這使團隊無法轉而執行其他任務
- 反饋太少，這使開發人員無法采取糾正措施
- 接收垃圾反饋，這使開發人員忽視反饋消息
- 所擁有的機器緩慢，這導致延遲反饋
- 依賴于膨脹的構建，這會降低反饋速度
 |
這些反模式延遲或者阻礙了使用持續集成能夠得到的好處。在第二部分中，我要介紹其他五種同樣具有欺騙性的實踐：
- 等到一天結束時才提交修改，造成瓶頸提交，通常造成破碎的構建，使開發人員備受挫折。
- 構建中只包含很少的自動過程，結果導致構建總是成功，造成持續忽視（Continuous Ignorance）和集成延遲問題。
- 沒有頻繁地通過代碼修改構建軟件，而傾向于定時構建，從而不利于構建修復。
- 相信代碼能夠在自己的機器上工作，因此只能在其他環境中發現問題。
- 沒有清除舊的構建工件，造成環境混亂，引起誤判和漏判錯誤。
再次強調，要得到持續集成的諸多好處，那就應該理解這些反模式 — 并避免它們。
名稱：瓶頸提交
反模式：開發人員在當日工作結束前提交代碼修改，引起集成構建錯誤，妨礙團隊成員正常下班。
解決方案：全天頻繁地簽入代碼。
|
|
瓶頸提交是簽入不夠頻繁 反模式的一種變體。它認為每天只要至少簽入一次代碼即可。但是，問題在于每個人都在同一時間 簽入。在 CM Crossroads 的一篇文章中，Slava Imeshev 描述了為什么大多數構建失敗都發生在晚上 5 點到 8 點之間（范圍再小一些，還包括午餐時間）。在 “五點鐘簽入（Five-O'Clock Check-In）” 中，Imeshev 將這種情況的發生與開人員傾向于每天結束之前簽入他們的代碼修改這種習慣聯系在一起（請參閱 參考資料）。
如果某個團隊的規定是在所有修改都提交而且運行了構建之前不能下班，那么五點鐘簽入 將使您很快失去很多朋友。等待代碼提交是件非常無聊的事情。想想如果構建出問題會怎么樣？我想會有許多人打電話回家去解釋為什么又得晚回家。
圖 1 演示了軟件開發團隊簽入的典型時間線。請注意庫提交放在晚餐時間前后，在下班時間之前。
圖 1. 瓶頸提交
當然，這個問題的解決方案就是頻繁地提交修改。通過頻繁提交，就會擁有更小但更頻繁的集成構建，而且在出現構建錯誤時，錯誤會較少，而且更容易修復。
五點鐘的言外之意很清楚，所以為了自己和團隊都應該頻繁地簽入代碼，讓五點鐘成為多數人的快樂時光。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
