17:10，宙斯終于開始了構建的過程。他從代碼源中檢出最新代碼，然后開始編譯，構建，并執行了所有的測試，從控制臺界面上，日構建的負責人(其中的一位程序員)似乎看到了有部分的測試沒有通過，他對剩下的人說，似乎有麻煩了。測試完成之后，將會從代碼中生成所有的API文檔，并進行代碼分析和測試覆蓋率分析，最新測試報告和各種其它的報告都將會發布到Web上。
最后。完成構建的軟件和相關的資料已經成功的發布了，時鐘指向17:18。"現在只是項目的早期，到了中后期，至少還需要20分鐘的時間"，老鳥程序員告訴沒有經驗的程序員，并讓大家去看看測試結果。一個程序員邊嘟囔，邊看log日志，"我在本機都已經測試過了呀，怎么會有錯呢。"檢查結果發現是環境問題，配置文件被人改動了�？磥�，集成過程中仍然少不了沖突的問題，只不過，這些問題可以被很快的發現，并很快的得以解決。
以上是一個典型的日構建過程，日構建的過程是完全自動化的，通過預先定義好的指令，機器將按照指令順序執行完所有的構建步驟。日構建中涉及的步驟是可選的。
日構建的價值
可能有些人認為日構建過于浪費時間，但是實際上，比起最后除錯的成本來說，日構建成本是微不足道的。當然，在企業中建立日構建制度確實需要花費不少的時間，但從長遠來看，這絕對是值得的。
從表面上看，日構建能夠減少最終的排錯成本，但這僅僅是日構建最基本的價值。實際上，日構建更為關鍵的作用是能夠引入日構建的制度。這是什么意思呢?日構建的思路將會為軟件企業的開發流程帶來變化：開發人員將會在日構建的制度下更加頻繁的協作，開發進度一目了然，軟件的質量也會更加的穩定。
軟件開發本身就是一項強調溝通和協作的活動。但是在日常的活動中，常常出現阻礙溝通的情況，例如需要溝通的雙方不在同一個地理位置、噪聲、溝通雙方的意愿等等。因此在軟件管理中需要提供一種方法，來鼓勵人們進行溝通。日構建就是其中的一種方法(但它并不是唯一的方法)。每一次的構建將會涉及到團隊中的所有成員，因此溝通是少不了的，在日構建實踐的驅動下，每位開發人員都朝著最終的目的-"成功的構建"努力。
在Alistair Cockburn的敏捷軟件開發的第三章中，詳細的闡述了團隊溝通和協作中的相關問題。例如溝通的實質，影響溝通的各種因素，以及如何克服他們。最后，他還論述了如何促進團隊的溝通，來打造一支成功的團隊。
在日構建的驅動下，項目的進度將會變得非常的明顯。每一天的構建結果將會通過某個渠道發布出來，團隊和團隊的老板可以看到軟件現在的樣子，項目的完成情況，出現的問題等等。這些信息構成了軟件開發的基本信息。不但可以清晰地描述出項目進度，也為管理人員安排計劃提供了基礎數據的支持。有了基本的量化數據，軟件開發才不是靠拍腦袋出成果的。
日構建的最后一個價值是提供了整合性。目前軟件開發中并沒有一種統一的管理軟件，未來似乎也很難做到，因為不同的軟件組織差異很大。在開發過程中，一些有價值的實踐被加入、集成到日構建的過程中，在日構建的推動下，這些優秀實踐很容易成為開發過程的一部分。在文章倡導的另一個優秀實踐-測試驅動開發實踐，就很容易集成到日構建中來。事實上，軟件測試是非常重要的，它已經成為日構建成功的判別因素。
選擇日構建還是持續集成
雖然日構建和持續集成的本質是相同的，但是他們在集成的頻率方面的差異也導致了一些管理上的差異：
首先，日構建樹立了一個明確的以工作日為單位的小目標，團隊的目的就是為了使代碼能夠通過每天的構建。開發人員在明確的目標的指導下，往往能夠發揮出很高的效率。持續集成則將這個頻率變得更小，只要你的代碼提交到代碼庫中，立刻就會檢驗你的成果，如果有問題，你必須立刻排除，否則，要么集成的過程無法繼續，要么出錯的開發人員的信箱被集成過程中的警告信息所填滿。這種做法對團隊的要求要更高一些。對于剛剛開始接觸日構建的團隊來說，可能會手忙腳亂。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
