日構建的最后一個價值是提供了整合性。目前軟件開發中并沒有一種統一的管理軟件，未來似乎也很難做到，因為不同的軟件組織差異很大。在開發過程中，一些有價值的實踐被加入、集成到日構建的過程中，在日構建的推動下，這些優秀實踐很容易成為開發過程的一部分。在文章倡導的另一個優秀實踐－測試驅動開發實踐，就很容易集成到日構建中來。事實上，軟件測試是非常重要的，它已經成為日構建成功的判別因素。
選擇日構建還是持續集成
雖然日構建和持續集成的本質是相同的，但是他們在集成的頻率方面的差異也導致了一些管理上的差異：
首先，日構建樹立了一個明確的以工作日為單位的小目標，團隊的目的就是為了使代碼能夠通過每天的構建。開發人員在明確的目標的指導下，往往能夠發揮出很高的效率。持續集成則將這個頻率變得更小，只要你的代碼提交到代碼庫中，立刻就會檢驗你的成果，如果有問題，你必須立刻排除，否則，要么集成的過程無法繼續，要么出錯的開發人員的信箱被集成過程中的警告信息所填滿。這種做法對團隊的要求要更高一些。對于剛剛開始接觸日構建的團隊來說，可能會手忙腳亂。
其次，日構建有一條非常明確的分界線，開發工作要么是完成，要么是沒有完成，不存在第三種狀態。
日構建的基礎實踐
日構建的基礎包括三個實踐：自動構建、統一代碼源和集成測試。
自動構建
自動構建的思路是通過腳本語言，而不是通過在IDE環境中點擊構建按鈕來完成項目的構建過程。日構建需要不斷的進行集成的工作，如果手工來完成這項工作，既費時，效果又不好。所以更聰明的做法是把這件工作給自動化。在早期的Unix環境中，都是采用Make編寫相應的腳本來完成構建的過程。隨著先進的IDE環境的發展，慢慢的人們就不愿意再編寫Make腳本了�？墒乾F在，為了自動構建的目標，我們需要回歸到手工編寫Make腳本的歷史上去。應該說，IDE環境中的構建方式側重于個人開發，而自動構建則側重于團隊開發
自動構建目標就是通過一個簡單的命令就能夠全部的構建過程。
統一代碼源
其次，保證一個開發團隊共享統一的代碼源。這時候我們需要使用版本控制工具。共享的代碼庫同樣也是XP的一個基本實踐。雖然XP還要求開發人員可以修改他人的代碼，但我們并不提倡這種做法，這要求團隊成員之間有非常高的默契程度。統一的代碼源能夠保證所有人的代碼都歸總到一起，這是日構建的基礎。如果沒有這一點的保證，每一次的構建我們都不得不把所有人的代碼集中起來，這無疑會使構建過程變成災難。
統一代碼源能夠保證任何一位團隊成員獲得所有的代碼，并以此為基礎進行開發。
集成測試
只是把代碼編譯通過并不能夠證明軟件可以正常工作，評價軟件的標準應該是測試。在日構建中必須要執行集成測試，來保證軟件確實是能夠工作的。
集成測試也是一個同義詞相當多的名詞，有人把它稱為驗證測試（BVT－Build Verification Tests），因為他們認為這種測試主要的目的是為了驗證構建的正確性。有些人把它稱為冒煙測試（Smoke Test），因為他們覺得這個測試的目的是運行軟件，看它是否會\"冒煙\"。
測試應該全部執行完畢，而不是遇到未被滿足的錯誤就放棄測試過程。測試將形成結果，成功的測試，失敗的測試，失敗測試的細節。最后的結果將通過某種方式通知給相應的人員，要求他們修改設計或測試（如果是測試本身的問題的話）。
集成測試是證明構建成功的關鍵因素。和構建一樣，集成測試也應該是自動化的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
