軟體工程進階之每日構建[3]：流程

　　在上一個文章
已經介紹了幾方面的準備工作，今天來說一下具體流程。對於流程的每一個環節，我會強調一下容易出問題的地方。

　　★提交代碼到原始程式碼控制伺服器
　　以下為了打字方便，簡稱為RCS（Revision Control System）。
　　和老式的軟體手工作坊不同，編程人員實現了某個功能點之後，不需要自己編譯成二進位並提交給測試。取而代之的是，把代碼提交到RCS。凡是使用過RCS的人，都應該知道如何提交代碼，我這裡就不細說了。
　　這個步驟的注意點有兩個：一個是保證提交的代碼是能編譯通過的；另一個是提交頻度的問題。這兩點在“善用工具
”中有提及，我這裡再另外補充一點：有很多程式員在工程中添加了檔案之後，忘記在RCS裡面也進行添加操作。雖然他/她本地的原始碼都可以編譯通過，但是在編譯伺服器上卻編譯失敗。

　　★從原始碼伺服器取出代碼到編譯伺服器
　　這個步驟是指令碼自動
進行的，不需要人為幹預。為了讓指令碼能夠自己跑起來，你可能需要在作業系統裡面設定一個“計劃任務”來啟動該指令碼。
　　該指令碼主要進行代碼的checkout/update（不同的RCS軟體叫法不同）操作。由於各種RCS軟體都會提供命令列方式。所以該指令碼只需要調用命令列就可以搞定。
　　這個步驟比較簡單，一般不會出什麼問題。在該指令碼執行完之後，就開始自動
執行後面的編譯指令碼。

　　★在編譯伺服器產生最終安裝包
　　這個步驟的指令碼比較複雜，得把所有需要編譯的模組都編譯過，然後再組裝成安裝包。
　
　幾乎所有編譯型的程式設計語言，在其開發套件中都內建有命令列的編譯器（比如JDK中的javac、VisualC++中的cl、Flex中的mxmlc等等）。有了這些編譯命令，再配合一些make工具（比如Java中的Ant、VisualC++的nmake、Posix上常用的
automake等等），就可以把一個工程編譯成若干二進位檔案。
　　在所有的項目都編譯通過後，下一步就可以製作安裝包了。大部分安裝包軟體（比如InstallShield、NSIS、RPM等）也都提供命令列方式。製作完安裝包之後，這個步驟也就大功告成了。
　　這個步驟比較容易出問題的一個地方在於編譯某個工程可能失敗。一旦發現失敗，就只能終止整個編譯過程。這時候最好自動
發出一個十萬火急的郵件，告知每日構建的負責人及相關項目/產品的負責人。然後那個導致編譯失敗的傢伙就有的好看了：輕則被臭罵一頓，重則被通報批評。
　　為什麼編譯失敗怎麼嚴重捏？因為每日構建號稱是軟體開發過程的心跳，自動編譯一失敗，就相當於心跳停了（下一個工作日，測試人員的工作都要受影響，項目進度也因此受影響），那當然很嚴重啦。所以，一般來說，規模越大的團隊，對導致編譯失敗的處罰越重。
　
　另一個容易出問題的地方在於增量編譯。所謂增量編譯就是在Make某個工程時，只編譯修改過的原始碼檔案（主要是對比原始碼檔案的修改時間和對應二進位檔案的修改時間來判斷）。有些工具在判斷增量編譯時間不夠智能，導致本該編譯的原始碼檔案沒有編譯（很容易引發詭異問題）。所以為了保險起見，我一般都使用全編譯（也就是編譯某個工程之前，把對應的二進位檔案都刪除）。

　　★提交安裝包到發行伺服器
　　假設安裝包被成功編譯出來，下一個步驟就是把安裝包自動
傳輸到發行伺服器上。這個負責傳輸的指令碼也是放在編譯伺服器上，在編譯指令碼執行完之後再被調用。
　　這個步驟一般也不會出什麼差錯，除非你公司的網路不穩定，導致傳輸過程檔案損壞（那你只能自認倒黴了）。

　　★從發行伺服器擷取安裝包進行煙霧測試 (Smoke Test)（可選）
　　如果你從來沒聽說過煙霧測試 (Smoke Test)，請看“這裡
”。先說明一下，煙霧測試 (Smoke Test)並不是必做的步驟，不過我建議還是做一下比較好。煙霧測試 (Smoke Test)是對軟體最主要的功能進行一些簡單基本的驗證，保證自動編譯出來的安裝包是基本可用
的。如果煙霧測試 (Smoke Test)不通過（和編譯失敗類似，也算是嚴重事故），則表明軟體本身有嚴重Bug，測試人員也就不用再費勁測試這個版本了（免得瞎忙乎）。
　　煙霧測試 (Smoke Test)一般由某個專門的煙霧測試 (Smoke Test)指令碼負責。這個指令碼一般放在測試伺服器上，也是通過諸如計劃任務來定時啟動，然後從發行伺服器上取下安裝包，並進行相關的驗證。

　　★測試人員從發行伺服器上擷取安裝包並測試
　　如果上述幾個環節都還順利，那麼，下一個工作日上班的時候，測試人員就可以從發行伺服器擷取到安裝包，並開始進行一天的測試工作了。
　　這裡有一個小建議：“測試人員下載安裝包並進行安裝”最好也是通過指令碼自動
來做。這樣的話，當測試人員上班的時候，當天淩晨做好的安裝包就已經自動
安裝在測試機器上了，測試人員一開啟電腦，就可以開始測試軟體了。

　　上述就是每日構建的幾個主要步驟，大伙兒看完之後如果有什麼問題，歡迎到Blog的評論裡面提問，我會盡量予以解答。

著作權聲明

本部落格所有的原創文章，作者皆保留著作權。轉載必須包含本聲明，保持本文完整，並以超連結形式註明作者編程隨想
和本文原始地址：

http://program-think.blogspot.com/2009/02/daily-build-3-proces.html