1、每天堅持
每日構造，最重要的就是“每日”。如Jim McCarthy所說，把每日構造看作是項目的“心跳”，沒有“心跳”的話，項目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一種隱含的比喻，把每日構造比作項目的“同步脈沖”(Microsoft Secrets, The Free Press, 1995)。 不同開發人員寫的代碼在他們的“脈沖”之間肯定都會存在“同步”的差異，但是必須有這樣一個“同步脈沖”，使得這些代碼能夠組合為一個整體。當項目組堅持每天把這些不同的“脈沖”組合到一起的時候，開發人員脫離整體的情況就會得到極大程度的杜絕。
有些項目組把這一過程簡化為“每周build一次”。這樣帶來的問題是，某一次build失敗后，可能要回溯好幾周才能找到原因。如果這種情況發生的話，已經得不到經常build帶來的好處了。
2、嚴格檢查每一次build
要保證每一次build的成功，就必須保證build后的結果（也可稱為build）是可以正常運行的，如果build不可運行，那么本次build被認為是不成功的，同時應該將修復此次build的工作提高到項目組最高級別來處理。
對于如何衡量一個build，每一個項目組都會定義一些自己的標準，這些標準需要設定一個嚴格的質量級別來處理那些特別嚴重的缺陷，同時也需要具有一定的伸縮性來忽略掉那些微不足道的缺陷，一些不適當的關心也許會使整個過程舉步為艱。
一個好的build起碼應該具備以下條件：
●能夠成功編譯所有的文件、庫，以及其它相關組件；
●能夠成功鏈接所有的文件、庫，以及其它相關組件；
●不能存在任何使得系統無法運行或者運行出錯的高級別故障；
●當然，必須通過冒煙測試
3、每天進行冒煙測試
冒煙測試應該是對整個系統流程從輸入到輸出的完整測試。測試不必是面面俱到的，但是應該能夠發現系統中較大的問題。冒煙測試應該是足夠充分的，通過了冒煙測試的build就可以認為是經過充分測試、足夠穩定的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
