我常常聽到一些開發人員抱怨說，他們要忙于修改那么多文件，哪有精力每天簽入代碼。實際上，這正是我要說的要點 — 為了每天提交源代碼修改，需要將任務劃分得更小。實際上，需要將編程任務劃分成小塊，這樣修改也會更小。
不要在一個大任務中實現一個業務對象上的所有特性，例如編寫 read()、write()、update() 和 delete() 方法的原型；而是應該首先編寫 read() 方法（以及對應的測試），然后簽入這個類，從而與整個代碼基集成。接下來，可以實現另一個方法，再次執行簽入，直到完成整個任務。這樣的話，就可以讓 CI 的好處最大化，而且會讓您確信自己的代碼可以與別人的代碼 相互配合。
請記住，即使您和您的團隊正確地執行許多 CI 實踐，如果團隊成員不堅持至少每天簽入一次源代碼修改，那么 CI 的好處會大打折扣。這常常會讓人誤以為 CI 是無效的，這種想法實在大錯特錯。
破碎的構建減慢了開發的節奏
名稱：破碎的構建
反模式：構建長時間破碎，導致開發人員無法簽出可運行的代碼。
解決方案：在構建破碎時立即通知開發人員，并以最高優先級盡快修復破碎的構建。
無論您信不信，構建破碎的時間越長，就越麻煩。這是因為文件、修改和依賴項越多，隔離缺陷就越困難。因此，當通知某人構建破碎時（通過電子郵件、RSS 或其他機制），他應該優先解決這個問題；否則，構建破碎的時間越長（尤其是對于頻繁修改代碼的團隊），就越難糾正。
破碎的構建不總是壞事。實際上，破碎的構建會讓您迅速地意識到軟件出了問題。當構建頻繁地 破碎或長時間破碎時，破碎的構建就會成為問題。在構建破碎的情況下，絕不應該置之不理。
用私有構建減少破碎的構建
防止破碎構建的有效技術之一是，在將代碼提交到存儲庫之前，運行私有構建（private build）。執行私有構建的步驟如下：
從存儲庫簽出代碼。
在本地修改代碼。
用存儲庫執行更新，從而集成其他開發人員所做的修改。
運行本地構建。
構建成功之后，將修改提交到存儲庫。
圖 1 說明了這種做法。注意，這個工作流強調頻繁地與存儲庫執行同步，從而保證定期簽入并限制破碎的構建 — 這真是一舉兩得！
圖 1. 運行私有構建減少破碎的集成構建
文章來源于領測軟件測試網 http://www.k11sc111.com/
