日構建和持續集成

為什么需要日構建

    日構建和持續集成是類似的，對開放源碼熟悉的人應該都知道Nightly Build。而持續集成這個詞來自XP方法，它的頻率可以比日構建更高，可以做到幾分鐘就進行一次集成，故而由此得名。在本文中，我們只討論日構建，而要將日構建轉換為持續集成是非常容易的。事實上，并沒有規定持續集成必須是以分鐘為單位進行的，如果你愿意，以一周為單位進行持續集成也是可行的。這樣區分的目的是為了更好的使用日構建或是持續集成技術：至少以天為單位，頻率越高，效果則越好。

    那么，什么是日構建呢？我們傳統開發軟件的流程一般是這樣，理解領域問題，然后分配任務，由不同的人負責不同的軟件部件，在開發完成之后，再把各人的部件整合起來，形成完整的軟件。這個思路看起來并沒有什么問題，但是在實踐中卻問題多多。

    首先，這種方式適合開發人員之間工作彼此沒有交集的情況，以前這種現象很常見，但是現在，隨著軟件規模的擴大、分工合作的加深，開發人員間的相互依賴程度越來越高，這種清晰的職責劃分已經變得越來越難了。

    其次，在軟件集成時，往往會出現各種各樣的問題，可是卻很難發現到底問題在哪里？公說公有理，婆說婆有理。每個人的代碼都沒有問題，結合到一起就出現大量的問題。

    所以日構建就將平時難得一見的集成工作轉換成頻繁進行的一件工作，從而使得原先如同噩夢般的集成變成了一件簡單的工作。這也是很容易理解的，如果集成工作幾個月才進行一次，誰能夠記起幾個月前的細節呢？但是如果集成以天，甚至以分鐘為單位進行，排除bug就變成一件很容易的事情了。

日構建范例

    現在的時間是下午的17:00，馬上就到日構建的時間了。團隊里四名程序員中的三位已經將自己的源代碼和測試代碼提交到了一臺名為宙斯的機器上，這臺機器將負責對代碼進行日構建。在他們提交代碼之前，已經通過了本機上的構建，并完成了測試。剩下的一位程序員似乎碰到了麻煩，他的代碼出現了一些問題，他現在需要編寫更多的測試來完善測試網?？磥頃r間來不及了，他只能夠在明天再做提交了。由于他的代碼沒有和其他人產生依賴，所以遲些提交也沒有關系，不過他在下個工作日的時候必須仔細的將最新的源代碼檢出到本地，在版本控制工具的幫助下，這項工作是很簡單的。

    17:10，宙斯終于開始了構建的過程。他從代碼源中檢出最新代碼，然后開始編譯，構建，并執行了所有的測試，從控制臺界面上，日構建的負責人（其中的一位程序員）似乎看到了有部分的測試沒有通過，他對剩下的人說，似乎有麻煩了。測試完成之后，將會從代碼中生成所有的API文檔，并進行代碼分析和測試覆蓋率分析，最新測試報告和各種其它的報告都將會發布到Web上。

    最后。完成構建的軟件和相關的資料已經成功的發布了，時鐘指向17:18。"現在只是項目的早期，到了中后期，至少還需要20分鐘的時間"，老鳥程序員告訴沒有經驗的程序員，并讓大家去看看測試結果。一個程序員邊嘟囔，邊看log日志，"我在本機都已經測試過了呀，怎么會有錯呢。"檢查結果發現是環境問題，配置文件被人改動了?？磥?，集成過程中仍然少不了沖突的問題，只不過，這些問題可以被很快的發現，并很快的得以解決。

    以上是一個典型的日構建過程，日構建的過程是完全自動化的，通過預先定義好的指令，機器將按照指令順序執行完所有的構建步驟。日構建中涉及的步驟是可選的。

日構建的價值

    可能有些人認為日構建過于浪費時間，但是實際上，比起最后除錯的成本來說，日構建成本是微不足道的。當然，在企業中建立日構建制度確實需要花費不少的時間，但從長遠來看，這絕對是值得的。

    從表面上看，日構建能夠減少最終的排錯成本，但這僅僅是日構建最基本的價值。實際上，日構建更為關鍵的作用是能夠引入日構建的制度。這是什么意思呢？日構建的思路將會為軟件企業的開發流程帶來變化：開發人員將會在日構建的制度下更加頻繁的協作，開發進度一目了然，軟件的質量也會更加的穩定。

    軟件開發本身就是一項強調溝通和協作的活動。但是在日常的活動中，常常出現阻礙溝通的情況，例如需要溝通的雙方不在同一個地理位置、噪聲、溝通雙方的意愿等等。因此在軟件管理中需要提供一種方法，來鼓勵人們進行溝通。日構建就是其中的一種方法（但它并不是唯一的方法）。每一次的構建將會涉及到團隊中的所有成員，因此溝通是少不了的，在日構建實踐的驅動下，每位開發人員都朝著最終的目的－"成功的構建"努力。

    在Alistair Cockburn的敏捷軟件開發的第三章中，詳細的闡述了團隊溝通和協作中的相關問題。例如溝通的實質，影響溝通的各種因素，以及如何克服他們。最后，他還論述了如何促進團隊的溝通，來打造一支成功的團隊。

原文轉自：http://www.anti-gravitydesign.com