jasmine214--love

原文：http://bbs.scmlife.com/thread-16603-1-1.html

一個項目想要成功，那配置管理的努力是必不可少的。如何做一個好的配置管理，同時減輕自己的負擔，那就是一個值得認真思考的問題拉。+ Z, Z7 d1 W/ J/ e) Q0 A* O1 J# i+ X
一個產品想要實現持續集成及日創建，那么非得有一套好的自動編譯系統支撐才可以，否則對于一個龐大的系統而言，一個配置管理就算累死也無法滿足需求的。
下面以我的經驗說說任何構建一個自動編譯系統。
$ E( i$ {4 U: N
為了更好的自動編譯，我想應該建立一個這樣的系統，那就是：
1、開發人員或定時觸發。
2、自動更新編譯環境。- P$ e; s  `% ^" c* U2 A0 L
3、自動編譯。
( b: C$ m* F  t: W9 w  l4、自動分析編譯結果。. U5 A! [6 X4 h6 Z2 ]+ |4 V9 v
5、自動通知開發、測試及配置管理員。$ C+ ~9 h& D! y4 m" c% d

下面我假設情況如下：
1、操作系統：平臺包括：HP-UX、SunOS、AIX、Linux 、Windows （均包括多個版本）、。  M! c$ t9 ": k
2、數據庫包括：oracle 8i、9i、10G
3、編譯器包括：aCC、CC、xlC、gcc、bcb(windows 上的集成開發環境) 、java（包括多個版本）/ R" N3 J* F$ "% L- R, D' b
4、項目規模超過千萬行代碼、模塊眾多、調用復雜。# H! A# y: "8 J% f7 C, G! j" `( E
那么在這樣一個情況下，如果我們考慮用一般的商用工具做，顯然成本是很高的。0 y; l( I* Y: x
對于這樣一個龐大，復雜的系統，我想在項目啟動后，首先要做的是：
1、定義編碼規范。0 L# S* D9 |' y2 @3 @1 G  h
2、定義C++及java的編譯選項（由于C++語言中編譯器及平臺版本不同，32、64位要求及數據庫的版本等不同要求，所以編譯選項顯然要提取出來單獨處理）。
3、定義Makefile 規范。
4、定義模塊目錄結構。
5、定義接口提供方式。
4 C( J  w$ v1 n* _  {, {+ m在定義以上內容的時 候，一定要遵循一個原則，符合命名規范、盡量可配置、易懂、易于理解。最后組合出的編譯命令的字符串不要太長（unix操作系統下，不同版本的shell 對一個命令的長度有不同要求、同時由于Makefile中如果有很多shell 腳本的話，編譯性能也會受影響）。3 U& P* h8 Q6 x& A8 E+ P
在我用過的系統中，make 工具，unix 平臺我們使用的是 GNU make 版本3.80，java 用的是 ant，windows 平臺C++用的是bcb 自帶的make，不過在編譯前先要將bcb的工程文件bpr文件轉換為Makefile文件，使用的工具是bpr2make（之所以不用bcb直接編譯， 主要是為拉自動編譯，自動分發編譯結果）。
2 [3 `" W; x% d- O
為了更好的跟蹤代碼及需求、bug變更情況，自動編譯系統，應該從開發人員提交代碼開始，到發布結束。( W- J% J4 O4 O/ E, a" m% s
流程如下：( V+ t: ~4 G+ }3 V* e' H; G8 ": k
1、開發人員提交代碼。
2、編譯腳本觸發，從版本庫更新代碼到編譯服務器。
3、設置編譯需要的環境變量。
4、構造編譯需要的Makefile。6 z% i( G5 ~. U2 l( q# I3 ^+ z9 ~
5、執行編譯。
6、分析編譯結果、記錄編譯結果。* N2 |9 P5 d% i: N. L
7、發郵件通知開發、配置管理、測試人員等相關人。# k5 |$ u9 ]2 `1 L2 ]0 I
8、更新到測試環境測試。  t, {9 D4 y3 ?7 v( Y5 q8 H- @
9、配置管理員發布。
2 ]2 b# _: ]5 q5 S# G! S* F
下面我以cvs或svn為源碼版本庫做作說明，需要寫一些適當的腳本，并且需要數據庫的配合才能工作的比較順利。
1、建議用戶表
( z  q  O: |- F0 R6 r2、在數據庫中建立產品表。
3、在數據庫中建立模塊表（需要記錄模塊優先級、模塊路徑、Makefile 文件的名稱等功能）。/ w* n9 y' D3 y3 R( L3 u9 x
4、建立需求表、任務單表、bug表、編譯記錄表。, s' t5 N4 m5 L& t) N- Q* X* [
5、編寫代碼提交腳本。實現提交代碼的同時，在編譯記錄表中增加記錄，并關聯需求單、任務單、BUG單功能。3 O+ N0 n3 e2 p' f
6、編寫自動編譯腳本。實現定時查詢數據庫，根據編譯單，進行編譯的功能。需要實現，獲取編譯單后，自動生成編譯環境所需的環境變量，構造編譯用 Makefile，更新待編譯代碼，編譯完成后分析編譯結果，給被編譯代碼打tag，獲取編譯結果的特征串，然后記錄到數據庫中，并發郵件通知開發人員、 測試人員及配置管理人員。

如果以上腳本實現，那么，不管你是要日創建還是隨時編譯，還是全系統編譯，都是輕松的事情拉。
雖然windows 平臺和unix 平臺差別很大，c++和java的差異也很大，但是如果大家將以上要求都用函數實現。我想遷移還是很方便的。1 t" v+ t  U' U* `" N% ~. L
尤其是腳本語言，多數是支持跨平臺的。
2 _* W: V3 t/ Q0 _0 C' q/ k" @) j) T& m這里主要可能碰到的問題是。7 r8 O- u! R2 t6 B% @
1、模塊結構規劃不合理。
: ?# j  z: ?' |* g. |0 w. T* E9 n  m2、公共調用文件的安裝問題。
3、模塊編譯順序的問題。對于復雜的系統，那么調用關系就決定了編譯順序，可能要多次調整。
4、編譯結果的安裝問題。最好是編譯完成通知測試人員，讓他們自己安裝。否則你自動殺掉他們正在測試的進程，他們會找你算賬的。( k/ |( ?$ e' {$ T: q
5、編譯結果的分析問題。編譯結果的分析就需要自己寫正則表達式來分析日志了，級聯編譯中是無法通過失敗信號獲取編譯失敗的，只能分析日志。
6、郵件發送問題。unix 平臺，配置好DNS和sendmail就好啦，windows平臺，如果沒有找到你所用腳本語言的郵件發送函數，那么你就的自己用telnet 加 smtp 協議實現拉。- h5 F! e" h1 R3 N% F5 e

6 `! g" j" Q- l$ f, U8 ^) W0 @# y# y可能有人奇怪我為什么要設計一個數據出來，我想如果有數據庫的話，方便維護人員根據編譯目標文件的特征串，查找出，這是那一次編譯的，生成他的源碼有那些，具體版本是什么。/ n3 i& _+ p9 n5 N) V& D  w
同時也可以查找出是為那個需求或BUG而修改代碼的，修改了那些地方等。同時也可以通過數據庫統計，分析出，模塊代碼的變更情況和工作量，進度等。8 W/ |; s& w& x* v( |
同時也可以分析出那些人老是提交錯，經常容易犯那些錯誤，編譯流程改進，作為cmmi 5級的數據提供。1 P/ e5 r$ D8 u0 j7 x' q' R0 ?
拉拉雜雜寫啦一大堆，希望對大家有用。

看到論壇里面有很多人詢問，工具的選擇和使用問題。個人建議：如果沒有采購的想法。那么我建議使用SVN做版本管理工具。理由如下：
一、SVN的開發團隊就是當初CVS的開發團隊。( q3 "9 K- W( V" O* i/ n/ S" D
1、正式由于CVS的很多缺陷，所以才放棄CVS，改開發SVN的。
2、CVS以后只會修改BUG，不會在出新功能拉。
3、CVS的權限功能很不完全，猶如雞肋。
二、SVN相對于CVS有很多優點。) o+ p; C1 M3 f
SVN的優點如下：
1、天然支持web。SVN服務器是可以和apache集成的，所以天然就支持HTTP協議，就可以通過互聯網訪問，同時可以使用apache的權限系統。而CVS只能通過CVSWEB來通過瀏覽器訪問。4 ^1 h3 V2 ]0 P( Z# [  q, `; "$ q
2、SVN支持文件的移動，支持文件的改名，支持目錄版本。
3、SVN提供拉API，提供拉各種語言的開發庫，這個是CVS所不支持的。CVS的二次開發，只能通過命令行的方式做腳本，否則你就要在CVS的C代碼中做接口，才能增加或修改功能。
4、SVN便于和自己開發的配置管理工具集成。原因如上。8 |3 g7 P  o/ _
5、SVN可以通過LDAP和公司的域結合起來，實現單點認證。
三、相對于CVS和SVN，VSS有幾個個很大的缺點。
1、VSS是基于CHECKOUT、鎖模式的，而SVN和CVS及基于CHECKOUT、合并模式的。后者顯然更適合協同開發，適合多人修改同一份代碼。而且作為配置管理員，也不用疲于奔命的去刪除鎖。
2、VSS只支持windows平臺，而CVS和SVN是跨平臺的。也許一時無所謂，但是如果有一天公司轉向類unix平臺，你就得遷移配置庫，重新編寫使用手冊，并且做培訓，為什么不把問題消滅在萌芽狀態呢。* }0 x4 `" `4 e2 `7 Q5 `% _
3、VSS是要共享目錄以便訪問。這樣在網絡病毒猖獗的日子里，你就和病毒做斗爭去吧。同時代碼安全和是一個大問題啊。
4、VSS是不支持web訪問的。9 V5 b: _" E1 U# ?1 X" o
5、權限配置也不夠友好。" S. y$ J, X8