每日構建 Daily build

一個好的辦法是每日構建（daily builds）。 每日構建意味著自動地，每天，完整地構建整個程式碼樹、（譯者按：“程式碼樹”，原文為source tree，意思是將整個專案原始碼的目錄，子目錄，檔案的位置儘可能事先固定下來，這樣在開發過程中各個模組間，各個檔案間的相對位置都不會混亂。原始碼樹指的就是一個專案所有的已經組織好的程式碼檔案。通常程式碼樹應該用版本控制軟體管理起來。雖然這個概念很基本，但是據我的觀察，國內還是有軟體公司在這方面做的不夠好的，所以有必要解釋一下。）

自動地 － 因為你設定程式碼每天在固定的時間構建。在Unix環境下使用cron，在windows下使用“任務計劃”。

每天 － 或者更頻繁. 當然每天構建的次數越多越好啦。但是有時候構建次數還是有上限的，原因和版本控制有關係，等會兒我會談到的。

完整地 －很可能你的程式碼有多個版本。多語言版本，多作業系統版本，或者高階低端版本。每日構建（daily build）需要構建所有這些版本。並且每個檔案都需要從頭編譯，而不是使用編譯器的不完美的增量編譯功能。

以下是每日構建（daily build）能帶來的好處：

1. 當一個bug被修正了，測試者可以很快得到最新的修正後的版本開始重新測試，以驗證bug是否真正地被修復了。
2. 開發人員可以更加確定他們對程式碼做的修改不會破壞1024個作業系統上的任何一個版本。驗證這一點不需要在他們的機器上安裝OS/2（IBM公司生產的PC機作業系統）。
3. 那些每天將修改過的程式碼匯入（check in）版本控制伺服器的開發人員知道，他們對一個模組匯入的修改不會拖別的開發人員的後腿。拖後腿的意思是，那些開發別的模組的程式設計師使用這個修改過的模組，出了問題，於是他們自己的模組也沒有辦法開發下去了。每日構建則不會有人拖後腿。如果把一個開發團隊比作一臺PC機，那麼團隊中的一個程式設計師對某個模組的修改導致其他人無法開發別的模組，相當於PC機發生了藍屏。當一個程式設計師忘記把他（她）新建立的檔案匯入到repository（指版本控制伺服器上的程式碼樹）時，這種開發過程中的“藍屏”會經常發生。因為在這個程式設計師自己的計算機上有這個檔案，所以他（她）構建 這個程式沒有問題。但是其他程式設計師是從版本控制伺服器上匯出（check out）程式碼的，由於伺服器上沒有這個檔案，他們遇到了連結錯誤（link error），無法繼續工作了。
4. 外部團隊（例如市場銷售部門，進行beta測試的一些客戶）可以獲得一個比較穩定的版本，這樣對他們開展自己的工作比較有利。
5. 假如你將每日構建出的二進位制檔案（例如一個可執行程式，一個dll等等）存檔管理，那麼當你發現一個非常奇怪的，無法解決的bug時，你可以通過對這些檔案進行二進位制搜尋（binary search）來確定什麼時候這個bug第一次出現。如果有對程式碼進行了完善的版本控制，你也可以找出是誰在何時對程式碼進行的匯入（check in）導致了這個bug。
6. 當開發者修正了測試者報告的一個錯誤時，如果測試者同時報告了發現錯誤時的構建的版本，開發人員可以直接在那個版本中測試是否bug真正被修復了。（譯者按：測試者報告出現了一個bug，只是報告了一個錯誤症狀，而錯誤的原因可能有多個，每個原因可能在不同的模組中。前文中的方法是為了避免只修正了一個模組中一個原因，別的模組由於在變動，於是掩蓋了而不是修復了bug）

以下是如何進行每日構建（daily build）的具體步驟。你需要用最快的電腦建立一個每日構建伺服器。寫一個指令碼，可以自動從版本控制伺服器中匯出（check out）完整的程式碼，（你當然使用版本控制，不是嗎？），然後對程式碼從頭開始進行構建（build），要構建所有的版本。如果你有一個安裝打包程式，也要在指令碼中自動執行。所有會賣給終端使用者的東西都要包括在構建過程中。把構建出來的版本放在各自的的目錄裡，不同時間構建的相同版本也應該按日期整理好，不要相互覆蓋。每天固定的時間執行這樣的指令碼。

1. 最關鍵的是所有這些步驟都應該由指令碼自動化完成，從匯出（check out）程式碼到將最終產品放在網上供使用者下載（當然在開發階段，產品是放在一臺測試伺服器上的）。要保證開發過程中的任何東西的任何記錄是由文件記錄的而不是由某個人的腦子來記錄的，這是唯一的辦法。否則你會碰到這樣的情況，產品需要釋出了，可是隻有Shaniqua知道如何將產品打包的，可是他剛剛被巴士撞了。在Juno公司（本文作者工作過的公司之一），要進行每日構建，你唯一需要學會的東西就是雙擊每日構建伺服器桌面上的一個快捷方式。
2. 如果你在發行程式的當天發現了一個小bug，沒有問題。修正它，然後重新執行每日構建指令碼，現在你可以安安心心的發行程式了。當然，黃金定律是每日構建指令碼應該是把所有的事情從頭做一遍，遵循這個定律就不會有什麼問題。
3. 將你的編譯器的警告引數設到最大（在微軟的VC中是-W4 ; 在GCC中是-Wall），當遇到任何一個最微小的警告時就應該停下來。
4. 如果每日構建失敗了，可能整個開發團隊的工作會因此進行不下去。當務之急是立刻找出原因，使得每日構建能成功進行下去。某天也許你會一天執行好幾次每日構建指令碼的。
5. 每日構建一旦失敗，應該自動地將失敗用email通知整個團隊。提取錯誤日誌中的恰當部分幷包括在email正文中也不是很難。每日構建指令碼也可以將當前的狀態報告整理成一個html檔案，自動釋出到一個所有人都可以訪問的web伺服器上，這樣測試者可以很快知道那個版本的構建是成功的。
6. 當我在微軟的excel團隊中工作時，我們的一個有效辦法是，誰導致每日構建（daily build）失敗，他（她）就得負責照看當日的每日構建（譯者按：微軟通常每日構建都在半夜），直到有另一個人導致構建失敗而接替他（她）。這樣做當然可以使每個開發者都小心不要因為自己程式碼的錯誤破壞了構建，更重要的是團隊中的每個人都可以學會每日構建（daily build）的原理。
7. 如果你的團隊在同一個時區工作，在午飯時間進行每日構建（daily build）是個不錯的主意。午飯前每個程式設計師匯入（check in）程式碼，這樣當程式設計師在吃飯時，構建系統在工作。當程式設計師吃完飯回來時，如果每日構建失敗了，所有的人也都在，可以儘快找出失敗的原因。當構建系統運作起來時，沒有人再會擔心別人匯入（check in）程式碼會妨礙自己的工作了。.
8. 如果你的團隊同時在兩個時區工作，計劃好每日構建（daily build）的時間使得一個時區的工作不會影響另一個時區的工作。在Juno公司，紐約程式設計師在晚上7：00匯入（check in）到版本控制伺服器。如果他們的匯入導致構建失敗，印度Hyderabad市（譯者按：印度科技重鎮）的程式設計師在紐約時間晚上8：00以後的工作幾乎無法進行下去。我們每天進行兩次每日構建（daily build），每次構建的時間都在兩地的程式設計師回家之前，這下就沒有問題了。

更多詳情

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29212814/viewspace-1122999/，如需轉載，請註明出處，否則將追究法律責任。