持續整合工程師應遵循的十項要領（上）

July 03 17:11~18:45

昨天談到「開發人員應遵循的七項持續整合要領」，接下來繼續介紹《Continuous Integration》這本書中所提到的持續整合工程師所應注意的十項要領，今天先介紹前五項：

1. Automate builds：持續整合顧名思義就是要經常地執行整合工作，如果整合的流程無法自動化，請問鄉民們會那麼勤勞手動的去執行整合的工作嗎？舉個例子，假設程式完成編譯之後，還需要人工介入，把編譯完成的二進制程式碼複製到某個地方，才可以執行測試。這樣的整合流程肯定久久才會被做一次，因為沒有人想當「人工介入」的那個人（附註說明：公司錢太多或是公家機關不在此限）。
2. Perform single command builds：持續整合的工作最好是只要執行一個命令列指令就可以完成，例如ant build.xml。建構腳本（build script）本身可以很複雜，但是執行建構腳本的方式一定要很容易。
3. Separate build scripts from your IDE：在古早、古早的時代，按下IDE上面的「F7、F8還是F9」按鈕（真的是太古早了，連Teddy都忘了Turbo Pascal和Turbo C IDE上面所提供的編譯熱鍵是什麼了），就等於完成了軟體的建構工作。隨著軟體系統越來越大，建構的工作越來越複雜，除了編譯、測試以外，還包含靜態程式碼分析、測試涵蓋率分析、產生安裝程式等。如果開發團隊繼續依賴IDE來建構軟體，那麼將會使得可應用的建構工作受限於IDE的功能，大大減少持續整合的威力。這還不是最慘的，如果依靠IDE來建構軟體，經常會發生「在我的電腦明啊明就可以成功建構，但是在其他人的電腦就不行」的這種靈異現象。為什麼會這樣？因為每位開發人員的開發環境設定各不相同，再加上IDE在建構軟體的時候私底下偷偷幹了什麼好事鄉民們也不太清楚，所以持續整合會要求開發團隊撰寫專門的建構腳本。
4. Centralize software assets：持續整合的產出物種類繁多，舉凡編譯過後的二進制程式碼、測試通過與失敗報表、測試涵蓋率報表、靜態程式碼報表、以及最重要的安裝程式等。這些產出物要找個地方統一存放起來，一般而言最簡單的方式就在放在持續整合系統的那台電腦的硬碟裡面。只要每次建構軟體所產生的產出物可以從持續整合系統的網頁上看得到就可以了。但是，硬碟空間有限，整合資料無窮。怎麼辦？以Teddy之前的經驗：
   • 安裝持續整合系統的時候，儘量購買市面上容量最大的硬碟。
   • 觀察專案產出物所需空間與成長情形，來決定需要保留多少天的資料。如果產出物容量不大，可以暫時都不刪掉也可以。
5. Create a consistent directory structure：每個相同類型的專案（例如Web程式、桌面程式、DLL函式庫程式）最好有相似的專案目錄結構，如此不但可以簡化持續整合腳本的撰寫，也可以促進團隊合作開發。以一個Java跨平台軟體的共享元件目錄範例，這些約定好的目錄會被持續整合工程師事先建好放在版本控制系統中。開發人員將所有的native code專案建構後的結果會被放在native目錄中；團隊自行開發的專案，建構結果會被放到in-house-src與in-house中；所有的驅動程式則是放在driver目錄。有了這個共享目錄，其他專案需要相關建構結果，便可到此共享目錄中抓取。除了這個共享目錄之外，每個專案也都會有自己的目錄結構。下圖是一個非常簡單的Java專案目錄結構，一般的商業軟體的專案目錄會稍微比較複雜一點。
   

***

看到這邊鄉民們可能會說：「啊我們公司又沒有專屬的持續整合工程師」。有沒有專屬的持續整合工程師不是重點，重點是團隊有沒有真正落實持續整合。如果有，那麼在沒有持續整合工程師的情況下，這些工作就會落在某位或是某幾位開發人員身上。看完這一集與上一集，鄉民們應該可以發現，持續整合的工作，對於「開發人員」與「持續整合工程師」各有不同的要求，遇到與持續整合有關的工作時，鄉民們只要記住自己正在扮演何種身分然後再參考該身分應該要注意的事項即可。

***

友藏內心獨白：開發個軟體搞的好像在Cosplay。