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