關於自動編譯的一點經驗

我關於自動編譯的一點經驗
一個項目想要成功，那配置管理的努力是必不可少的。如何做一個好的配置管理，同時減輕自己的負擔，那就是一個值得認真思考的問題拉。
一個產品想要實現持續集成及日創建，那麼非得有一套好的自動編譯系統支撐纔可以，否則對於一個龐大的系統而言，一個配置管理就算累死也無法滿足需求的。
下面以我的經驗說說任何構建一個自動編譯系統。

爲了更好的自動編譯，我想應該建立一個這樣的系統，那就是：
1、開發人員或定時觸發。
2、自動更新編譯環境。
3、自動編譯。
4、自動分析編譯結果。
5、自動通知開發、測試及配置管理員。

下面我假設情況如下：
1、操作系統：平臺包括：HP-UX、SunOS、AIX、Linux 、Windows （均包括多個版本）、。
2、數據庫包括：oracle 8i、9i、10G
3、編譯器包括：aCC、CC、xlC、gcc、bcb(windows 上的集成開發環境) 、java（包括多個版本）
4、項目規模超過千萬行代碼、模塊衆多、調用複雜。
那麼在這樣一個情況下，如果我們考慮用一般的商用工具做，顯然成本是很高的。
對於這樣一個龐大，複雜的系統，我想在項目啓動後，首先要做的是：
1、定義編碼規範。
2、定義C++及java的編譯選項（由於C++語言中編譯器及平臺版本不同，32、64位要求及數據庫的版本等不同要求，所以編譯選項顯然要提取出來單獨處理）。
3、定義Makefile 規範。
4、定義模塊目錄結構。
5、定義接口提供方式。
在定義以上內容的時候，一定要遵循一個原則，符合命名規範、儘量可配置、易懂、易於理解。最後組合出的編譯命令的字符串不要太長（unix操作系統下，不同版本的shell 對一個命令的長度有不同要求、同時由於Makefile中如果有很多shell 腳本的話，編譯性能也會受影響）。
在我用過的系統中，make 工具，unix 平臺我們使用的是 GNU make 版本3.80，java 用的是 ant，windows 平臺C++用的是bcb 自帶的make，不過在編譯前先要將bcb的工程文件bpr文件轉換爲Makefile文件，使用的工具是bpr2make（之所以不用bcb直接編譯，主要是爲拉自動編譯，自動分發編譯結果）。

爲了更好的跟蹤代碼及需求、bug變更情況，自動編譯系統，應該從開發人員提交代碼開始，到發佈結束。
流程如下：
1、開發人員提交代碼。
2、編譯腳本觸發，從版本庫更新代碼到編譯服務器。
3、設置編譯需要的環境變量。
4、構造編譯需要的Makefile。
5、執行編譯。
6、分析編譯結果、記錄編譯結果。
7、發郵件通知開發、配置管理、測試人員等相關人。
8、更新到測試環境測試。
9、配置管理員發佈。

下面我以cvs或svn爲源碼版本庫做作說明，需要寫一些適當的腳本，並且需要數據庫的配合才能工作的比較順利。
1、建議用戶表
2、在數據庫中建立產品表。
3、在數據庫中建立模塊表（需要記錄模塊優先級、模塊路徑、Makefile 文件的名稱等功能）。
4、建立需求表、任務單表、bug表、編譯記錄表。
5、編寫代碼提交腳本。實現提交代碼的同時，在編譯記錄表中增加記錄，並關聯需求單、任務單、BUG單功能。
6、編寫自動編譯腳本。實現定時查詢數據庫，根據編譯單，進行編譯的功能。需要實現，獲取編譯單後，自動生成編譯環境所需的環境變量，構造編譯用Makefile，更新待編譯代碼，編譯完成後分析編譯結果，給被編譯代碼打tag，獲取編譯結果的特徵串，然後記錄到數據庫中，併發郵件通知開發人員、測試人員及配置管理人員。

如果以上腳本實現，那麼，不管你是要日創建還是隨時編譯，還是全系統編譯，都是輕鬆的事情拉。
雖然windows 平臺和unix 平臺差別很大，c++和java的差異也很大，但是如果大家將以上要求都用函數實現。我想遷移還是很方便的。
尤其是腳本語言，多數是支持跨平臺的。
這裏主要可能碰到的問題是。
1、模塊結構規劃不合理。
2、公共調用文件的安裝問題。
3、模塊編譯順序的問題。對於複雜的系統，那麼調用關係就決定了編譯順序，可能要多次調整。
4、編譯結果的安裝問題。最好是編譯完成通知測試人員，讓他們自己安裝。否則你自動殺掉他們正在測試的進程，他們會找你算賬的。
5、編譯結果的分析問題。編譯結果的分析就需要自己寫正則表達式來分析日誌了，級聯編譯中是無法通過失敗信號獲取編譯失敗的，只能分析日誌。
6、郵件發送問題。unix 平臺，配置好DNS和sendmail就好啦，windows平臺，如果沒有找到你所用腳本語言的郵件發送函數，那麼你就的自己用telnet 加 smtp 協議實現拉。

可能有人奇怪我爲什麼要設計一個數據出來，我想如果有數據庫的話，方便維護人員根據編譯目標文件的特徵串，查找出，這是那一次編譯的，生成他的源碼有那些，具體版本是什麼。
同時也可以查找出是爲那個需求或BUG而修改代碼的，修改了那些地方等。同時也可以通過數據庫統計，分析出，模塊代碼的變更情況和工作量，進度等。
同時也可以分析出那些人老是提交錯，經常容易犯那些錯誤，編譯流程改進，作爲cmmi 5級的數據提供。