# 十、每日連編是朋友 自動地一因為你設定代碼每天在固定的時間構建。在Unix環境下使用cron在windows下使用“任務 計劃”。 每天一或者更頻繁.當然每天構建的次數越多越好啦。但是有時候構建次數還是有上限的，原因和 版本控制有關系，等會兒我會談到的。 完整地一很可能你的代碼有多個版本。多語言版本，多操作系統版本，或者高端低端版本。每日構建 (daily build)需要構建所有這些版本。并且每個文件都需要從頭編譯，而不是使用編譯器的不完美的增 量編譯功能。 以下是每日構建（daily build)能帶來的好處： 當一個bug被修正了，測試者可以很快得到最新的修正后的版本開始重新測試，以驗證bug是否真正地 被修復了。 開發人員可以更加確定他們對代碼做的修改不會破壞1024個操作系統上的任何一個版本。驗證這一點 不需要在他們的機器上安裝OS/2 (IBM公司生產的PC機操作系統）。 那些每天將修改過的代碼導入（check in)版本控制服務器的開發人員知道，他們對一個模塊導入的 修改不會拖別的開發人員的后腿。拖后腿的意思是，那些開發別的模塊的程序員使用這個修改過的模塊， 出了問題，于是他們自己的模塊也沒有辦法開發下去了。每日構建則不會有人拖后腿。如果把一個開發團 隊比作一臺PC機，那么團隊中的一個程序員對某個模塊的修改導致其他人無法開發別的模塊，相當于PC機 發生了藍屏。當一個程序員忘記把他（她）新建立的文件導入到repository (指版本控制服務器上的代碼 樹）時，這種開發過程中的“藍屏”會經常發生。因為在這個程序員自己的計算機上有這個文件，所以他 (她）構建這個程序沒有問題。但是其他程序員是從版本控制服務器上導出（check out)代碼的，由于 服務器上沒有這個文件，他們遇到了鏈接錯誤（link e「「o「），無法繼續工作了。 外部團隊（例如市場銷售部門，進行beta測試的一些客戶）可以獲得一個比較穩定的版本，這樣對他 們開展自己的工作比較有利。 假如你將每日構建出的二進制文件（例如一個可執行程序，一個dll等等）存檔管理，那么當你發現一 個非常奇怪的，無法解決的bug時，你可以通過對這些文件進行二進制搜索（binary search)來確定什么 時候這個bug第一次出現。如果有對代碼進行了完善的版本控制，你也可以找出是誰在何時對代碼進行的導 入（check in)導致了這個bug。 當開發者修正了測試者報告的一個錯誤時，如果測試者同時報告了發現錯誤時的構建的版本，開發人 員可以直接在那個版本中測試是否bug真正被修復了。（譯者按：測試者報告出現了一個bug,只是報告了 一個錯誤癥狀，而錯誤的原因可能有多個，每個原因可能在不同的模塊中。前文中的方法是為了避免只修 正了一個模塊中一個原因，別的模塊由于在變動，于是掩蓋了而不是修復了bug)以下是如何進行每日構建（dai lybui ld)的具體步驟。你需要用最快的電腦建立一個每日構建服務器。 寫一個腳本，可以自動從版本控制服務器中導出（checkout)完整的代碼，（你當然使用版本控制，不是 嗎？），然后對代碼從頭開始進行構建（build)，要構建所有的版本。如果你有一個安裝打包程序，也要 在腳本中自動運行。所有會賣給最終用戶的東西都要包括在構建過程中。把構建出來的版本放在各自的的 目錄里，不同時間構建的相同版本也應該按日期整理好，不要相互覆蓋。每天固定的時間運行這樣的腳本。 最關鍵的是所有這些步驟都應該由腳本自動化完成，從導出（checkout)代碼到將最終產品放在網上 供用戶下載（當然在開發階段，產品是放在一臺測試服務器上的）。要保證開發過程中的任何東西的任何 記錄是由文檔記錄的而不是由某個人的腦子來記錄的，這是唯一的辦法。否則你會碰到這樣的情況，產品 需要發布了，可是只有Shaniqua知道如何將產品打包的，可是他剛剛被巴士撞了。在Juno公司（本文作者 工作過的公司之一），要進行每日構建，你唯一需要學會的東西就是雙擊每日構建服務器桌面上的一個快 捷方式。 如果你在發行程序的當天發現了一個小bug,沒有問題。修正它，然后重新運行每日構建腳本，現在你 可以安安心心的發行程序了。當然，黃金定律是每日構建腳本應該是把所有的事情從頭做一遍，遵循這個 定律就不會有什么問題。 將你的編譯器的警告參數設到最大（在微軟的VC中是-W4 ;在GCC中是-Wall),當遇到任何一個最微 小的警告時就應該停下來。 如果每日構建失敗了，可能整個開發團隊的工作會因此進行不下去。當務之急是立刻找出原因，使得 每日構建能成功進行下去。某天也許你會一天運行好幾次每日構建腳本的。 每日構建一旦失敗，應該自動地將失敗用email通知整個團隊。提取錯誤日志中的恰當部分并包括在 email正文中也不是很難。每日構建腳本也可以將當前的狀態報告整理成一個html文件，自動發布到一個所 有人都可以訪問的web服務器上，這樣測試者可以很快知道那個版本的構建是成功的。 當我在微軟的excel團隊中工作時，我們的一個有效辦法是，誰導致每日構建（daily build)失敗， 他（她）就得負責照看當日的每日構建（譯者按：微軟通常每日構建都在半夜），直到有另一個人導致構 建失敗而接替他（她）。這樣做當然可以使每個開發者都小心不要因為自己代碼的錯誤破壞了構建，更重 要的是團隊中的每個人都可以學會每日構建（daily build)的原理。 如果你的團隊在同一個時區工作，在午飯時間進行每日構建（daily build)是個不錯的主意。午飯前 每個程序員導入（check in)代碼，這樣當程序員在吃飯時，構建系統在工作。當程序員吃完飯回來時， 如果每日構建失敗了，所有的人也都在，可以盡快找出失敗的原因。當構建系統運作起來時，沒有人再會 擔心別人導入（check in)代碼會妨礙自己的工作了。 如果你的團隊同時在兩個時區工作，計劃好每日構建（dailybuild)的時間使得一個時區的工作不會 影響另一個時區的工作。在Juno公司，紐約程序員在晚上7: 00導入（checkin)到版本控制服務器。如果 他們的導入導致構建失敗，印度Hyderabad市（譯者按：印度科技重鎮）的程序員在紐約時間晚上8: 00以 后的工作幾乎無法進行下去。我們每天進行兩次每日構建（dailybuild)，每次構建的時間都在兩地的程 序員回家之前，這下就沒有問題了。