序

从5月开始的这段时间里，一直参与这个测试驱动开发（TDD）的实践和评估实验。关于XP项目实践的一些配置管理有了一些比较全面的经历和认识。这也是我在此实习的最后一周，马上就要回学校准备论文和毕业了。工作已经完结，不必计较得失；只想在此记录，作为总结，也作为文档备份。如果有幸能给看到这篇文档的人提供一些帮助，聊以辛苦记录之慰藉；如若不满，仍完鸡蛋后，别忘给出宝贵意见，一起探讨，共同进步。（呵呵，拱手，献丑了～）

说一下极限编程（eXtreme Program XP），是个程序员都至少有所了解，单说单元测试和持续集成早已深入民心。XP作为一套方法体系，有诸多的关键实践（见下图）。TDD是应用XP的一种方式。关于XP和TDD应用，以后有时间再撰文讨论，此篇将主要记录TDD实验用到的配置管理系统。XP可以来这里学习（Agile Alliance、extremeprogramming、xprogramming），有很多的资料可以下载哦，全英文；不好意思，要系统学还是来这里，谁让人家“先知”Kent Beck、Martin Flower都是说英语的。幸好，还有XP系列中文书籍也可以作为参考《解析极限编程——拥抱变化》、《规划极限编程》、《极限编程实践 》,《敏捷软件开发：原则、模式与实践》和《重构》在动手XP实践之前看这两本。

简单介绍一下这个实验。目前国内完全采用XP开发流程的几乎没有，大多只会用到XP的几个实践。原因嘛，中国有中国特色，XP的实践比如说结队编程不适合国情；国内的某些“资本家”恨不得程序员都有分身术，恨不得一天有48个小时，怎么舍得让两个人去坐一起，用一台电脑，做一件事？另一个重要原因，采用XP要承担风险，没有前人的经验可以借鉴，更不知道是不是真的有效。这个实验的目的就是应用TDD和XP的其它实践，并验证TDD比传统的开发流程更有效。（限于职业道德和保密协定，我将不会透露任何关于实验结果的内容；如果不慎泄漏，请提醒，谢谢。）测试驱动开发请参考《测试驱动开发》。

这次所用的配置管理系统几乎全是开源或者免费的，对于小型项目管理还是很有参考价值的；涉及开源软件较多，或许一次不能记录完全，希望能有更多精神支持。

服务系统配置篇

服务系统将主要介绍基于Linux服务器下的邮件服务、域名服务、网页服务、数据库服务等软件的选用和配置。

操作系统选用Fedora Core 2，原因很简单，现在好多开源软件都是在linux下使用，象CVS、Bugzilla等，即使能在Windows下安装，也不好使用。Fedora Core可是一个好东东，用它自己的话说：The Fedora Project is an open source project sponsored by Red Hat and supported by the Fedora community. It is also a proving ground for new technology that may eventually make its way into Red Hat products. It is not a supported product of Red Hat, Inc.(这里是fedora项目的主页)大名鼎鼎的Red Hat，自不必多说；redhat自从出到9之后，就不再提供个人版的支持，fedora core作为一个替补上来了，由community支持，并且开源，大家都来做，所以fedora的图形界面已经非常漂亮舒服了。开源意味免费，免费意味……呵呵；至此也不敢夸Fedora Core作为Linux服务器，会有怎样的稳定性，不过在这几个月的期间，服务器至少没有当掉而导致项目不能继续。

Fedora Core 现在出到了版本4，不过我们当初选用2，出来得越早越稳定呀，其实是当初我只借到2的盘，哈哈。这是我第一次使用fedora，不过一用上了就爱不释手，清新的界面，方便的安装；以至于后来把2拿到本本上摆弄郁闷了我一把，才使这种喜爱大打折扣。Fedora Core 2竟然对本本的USB和PS2鼠标支持不好，以至于在本本上只能一直使用烦人的触摸板（Compaq的，所以没有IBM的红点鼠标）；网上找了很多文档也没有解决，原因是Fedora Core 2对本本的鼠标本来就支持不好。上周我自己刻好Fedora Core 3，重新装了一遍，什么都不用配置，就认出了我的USB鼠标。Yes！还是版本越新越好呀。（Fedora Core 4来这下，这是香港的一个mirror，4个iso同时flashget，两个小时over，还是很快的。）

Fedora Core 安装。如果有Linux基础，安装fedora很easy，不用一个小时。时间不在于安装，在于服务的配置。安装过程中，有一个选择需要注意一下：显示器的类型选择。听一个同学说，如果选择不对，有可能烧掉显示器！！（是不是有点耸人听闻呀！）很不幸，我没有烧过，不能提供任何经验。不过显示器类型和鼠标类型选择正确，对于安装成功还是很有必要的。宁可信其有。不过我上次在安装fedora core 3的时候，选用图形安装，在安装的图形界面下方居然一条花屏，以至于根本看不到上一步和下一步，也不知道是不是我的显示器类型没有选对，最后只能通过print screen来看截屏。有三种安装选择：个人应用、工作站和服务器。也可以自定义，我就可以选择安装服务包，而不用安装开发包。不懂linux，不打紧，参考Red Hat Linux 9 应用与管理系统丛书就行了；包括三本：桌面应用、系统管理和网络服务。fedora core2安装和配置和这三本书上讲述的还是差不多的，虽然有一点很小的出入。

邮件服务器配置。XP强调团队的交流和沟通，email自然是很好的方式；而且后面我们要介绍的bug追踪系统，有自动发email通知的功能，也需要email服务器的支持。当然可以采用公网上的email，但是配置一个局域网内的email服务器，安全快捷，为什么不用。Linux的邮件服务器有Sendmail、Qmail和Postfix等，Sendmail最安全，使用最多，配置也更复杂。这里不作这三个的区别，Fedora Core2自带Sendmail8，我们就用它。

1、安装

Fedora Core2提供了sendmail的RPM包，如下：

sendmail:sendmail服务器

sendmail-cf:与配置相关的文件和程序

sendmail-doc: sendmail服务器文档

//查看是否安装，没有则安装

#rpm –qa|grep sendmail

//sendmail在cd1，sendmail-cf和sendmail-doc在cd3

#rpm –ivh sendmail-…….rpm

//m4工具能生成sendmail的配置文件

#rpm –ivh m4-…….rpm

2、启动

修改/etc/mail/sendmail.cf的O DaemonPortOptions=Port=smtp,Addr=127.0.0.1,Name=MTA中的Addr为本机IP，或者干脆去掉Addr属性

//启动

#service sendmial start

3、配置

sendmail的cf配置文件语法相当复杂，没有人试图自己重新编写。幸运的是可以先编写mc宏配置文件，然后通过m4工具转换成cf配置文件。对于mc和cf的语法，这里不再讨论，使用的默认的配置和简单修改，已经能够启动和使用。

另外，可以修改/etc/mial/local-host-names添加邮件后缀域名（后面DNS配置的）。sendmial的Access数据库能打开投递代理功能，使用aliases数据库能使用别名。关于配置带认证的sendmail等高级功能，可以参考那三本书。

4、收发邮件

imap包提供了对POP和IMAP两种协议的支持，安装配置imap服务器后就可以收发邮件了。使用imap的默认配置应该就可以了，但不知道为什么，我在启动时老是出错，找了很多文档也没有解决，是关于saslauthd认证的问题，最后不得不启用dovecot代替。dovecot也是fedora自带的，这里有dovecot和imap的比较。可以用mail命令来收发邮件了，一会配置好DNS，就可以用outlook等客户端来收发。

域名服务器配置。配置好DNS，就可以用xxx.com而不是用IP地址来收发邮件。如果很清楚DNS查询模式和域名解析过程，那么恭喜，你可以把这个简单问题复杂化。

安装Fedora提供的如下RPM包：

bind:域名服务器软件

bind-utils:包含DNS查询工具软件

caching-nameserver:包含惟高速缓存服务器的配置文件

安装好之后，需要配置住域名服务器，包括：修改主配置文件和创建反向解析数据库文件。bind的配置，网上有很多例子，修改成自己想要的就行了。需要注意的是在Fedora Core上的新版的bind，有一些配置跟之前不太一样。主要是加上了chroot的动作，所以我们的dns路径较之前不一样，如果你的dns设定好了，而无法作用，就有可能是这个chroot的问题，刚好被我撞上了。/etc/sysconfig/named有一行ROOTDIR=/var/named/chroot，这样关于bind的所有配置原始 不是原来的/etc/named.conf，而是/var/named/chroot/etc/named.conf，需要配置的是chroot目录下的bind配置，否则就不起作用。另外，重新启动dns时如果发现了Stopping named: rndc: connect failed: connection refused这个问题的话，可以将/etc/rndc.key的內容copy到named.conf里然后重新启动一二次。

Web服务器。Apache默认安装了，启动就行。Tomcat下载一个，启动就行。都很easy，倒是把Tomcat加载在Apache上，作为系统服务，可以省去手工敲命令的麻烦，看这里。

数据库服务器。知名度，MySQL没得说，简单好用还免费。只是3.23版竟然不支持外键和视图，高级功能还是有待发展呀。据说MySQL4支持视图，没有研究过。MySQL管理主要是做好权限设置和备份。

配置管理系统篇

软件配置管理系统范畴很广：版本控制、构建管理、需求变更管理、缺陷管理、工作空间管理、并行开发支持、过程管理、发布管理、权限控制、报告支持……（晕了吧）。目前大多数配置管理工具只支持其中一项或者几项功能，完成的配置管理方案需要集成各种不同的工具系统。

1、 版本控制

版本控制系统是必要的，集中放置，统一管理，控制版本，安全有效；也是实践XP的

倡导的“集体所有”“共享”的思想。

专门对当前流行的ClearCase、Firefly、CVS、PVCS、VSS、STARTEAM等产品专门作了一个调查报告。企业级的ClearCase和Firefly等，功能强大，配置也很复杂，价格也非常昂贵，一个licence几千美金不是一般人能用得起。相比而言，Hansky 的Firefly比较划算，有比较完善的配置管理解决方案。免费就是开源的CVS了，严格上讲，只能算是一个版本控制系统，开发人员当然最喜欢这样简单适用的了。完整的配置管理，当然是涉及企业的各个方面，包括各个部门的人员。我觉得配置管理已经涵括了项目管理的很大一部分，配置管理到位可以说是项目管理成功的必要条件了。

最后当然选用了CVS，实验的硬件和人力投资已经差不多有十几万了，不好再有更大的投入。关于CVS的配置和使用参考另一篇引用的文章，其中我作了整理和修改。CVS对于权限控制还是相当麻烦的，只能通过writer和reader以及linux的文件权限来控制，但是据说可以通过CVS提供的接口扩展来实现复杂的权限控制，我没有试过。

2、缺陷跟踪（Bug Tracking）

在原来的一家工作的时候，也经历过使用excel来记录bug的原始时代：测试人员记录下bug，然后发excel给开发人员。采用一个好用的缺陷跟踪系统，好处自然明显：集中管理bug、自动发送通知、bug分析统计等。

目前开源的Bug Tracking System还是有不少的：GNATS、bugzilla、mantis，bugzero虽然不是开源，不过也有免费版。很高兴，还有一个国产的叫BugFree，冲着他们的目标“BugFree的发展目标：代替BugZilla和Mantis，成为最流行的Bug管理系统！“的份上，去看看。还有一个URTracker，用它自己的话说是“应用于Bug跟踪、问题跟踪、任务跟踪、服务跟踪……”，我还特地试用了一下，界面很漂亮。

这么多工具，用哪一个？我们当然作了一个分析调查报告，很可惜，国产的都被排除在考虑之外。相信国产的一定可以发达兴旺，但目前成熟的还是国外的。开源软件在国内没有得到更好的重视，相反，日本、台湾和香港等地方发展得很好，从网上所查的文档的多少可以看出来。下面谈一下Gnats、bugzilla、bugzero和mantis的比较。

最后选用bugzilla，虽然安装配置复杂，无疑它是最强大了，尤其看好的它丰富的报表分析功能，对于我们的实验分析很有好处。而且，当初就考虑到可能需要对功能扩展，需要对bug的结果进行分析，如果采用Gnats，文件的读写将是一个很大麻烦，采用bugzilla的mysql数据库作为接口，问题迎刃而解。

Mantis应该也是一个简单易用的工具，参见八进制的帖子“使用Mantis跟踪bug”。

谈谈bugzilla。安装确实是很折腾人，虽然可以采用自动安装，让bugzilla自己去搜索依赖的perl module，但是网络不尽人意，不知道何时就会断网，以至于导致安装失败无法再重复安装的可能也是有的。保险的办法也有，那就是自己下载所有的bugzilla 依赖的perl module，然后手动安装。问题也有，下载所有的perl module需要耗费N多时间和精力，而且很多的模块之间有版本上依赖关系。

Bugzilla依赖的全部perl模块。系统：Linux ，Bugzilla version：2.18rc3。（前面表示模块名，数字表示版本号，括号内：any表示任何版本和推荐版本、对应真实工具包名。）

Appconfig 1.52

CGI 2.93

Data:Dumper (any 2.121)

Date::Format2.21(TimeDate-1.16)

DBI 1.36

DBD:Mysql2.1010

File::Spec 0.82(PathTools-3.05)

File::Temp(any)(File-Temp0.16)

Template 2.08(Template-Toolkit-2.14.tar.gz)

Text::Wrap 2001.0131(Text-Tabs+Wrap-2001.0929)

Optional(不必非得安装，主要是报表功能和扩展功能的支持)

GD 1.20

Chart::Base 1.0 (Chart-2.3)

GD::Graph(any)

GD::Text::Align(any) (GDTextUtil-0.86.tar.gz)

PatchReader 0.94 (0.9.5)

Bugzilla安装。以上这些模块都是我已经安装过的，使用正常。如果希望手动安装，来这里获取这些perl模块。Linux下安装可以参考IBM devWork上的这篇文章，windows下安装，参考bugzilla.org上的这篇文章。如果还有问题，可以再讨论。

Bugzilla使用。参考ycw专栏上的Bugzilla简明使用手则。更详细的请参考 王晓昕 梁太平 整理的《BUGZILLA的使用》。开发人员和测试人员（或QA）的使用，只需要作一个简单的学习，Bugzilla权限管理和定制则需要一个摸透Bugzilla的管理员。以上两篇已经讲述得很完全，这里不再赘述。

Bugzilla扩展。这里所说的扩展，是根据获取实验数据的需要，即统计Bug opened/closed的个数和平均停留时间，这些都是评价一个项目好坏的依据。这里应验了之前提到的选用bugzilla的原因：以mysql数据库作为接口进行编程，你想用什么语言都行。Bugzilla把所有的bug和bug的每一次状态变换都完整的记录在数据中，我用Java编写了程序，不间断地运行在Linux服务器上，每天定时计算和收集以上三类数据，并自动保存到一个电子表格csv文件；这完全是一个自动化的过程，节省我们不少的人工时间和精力。另外，尚有问题等待解决，首要就是对于Reopened的Bug，两次状态变换之间的时间需要去除，不然停留时间不仅仅是误差，而是重大缺陷，会严重影响平均停留时间的大小。

3、变更控制

需求变更被列为项目经历最头痛的事情之一。接受需求可谓是项目开始的标志，需求的改变直接影响整个开发过程。RUP的思想说明，需求也是一个迭代发展的过程。由此，最头痛其实不应该是不可避免的变更，而是变更管理的无序。

需求变更管理的理论，已经研究得很成熟。主要包含如下内容：

a.建立需求基线，控制变更范围。需求的基线是指是否容许需求变更的分界线。

b.制定变更控制流程，从变更申请、评审到最后应用的一个完整流程。

c.成立变更控制委员会（CCB），负责裁定接受哪些变更。

关于变更的管理远不止这么简单，我想今后还应该花些时间在研究最佳的管理方案这方面。

至于CCB，曾经参与的一个银行个人信用评估系统，人员是这么设置的：项目Leader、需求分析人员、配置管理人员、开发组人员、测试或QA人员，人员各一；可以参考讨论，对于一个小型项目组，可能一个人会身兼数职。

变更控制流程图，如下：（出自一个RUP的doc）。还有一个更简单明了的，参见《软件开发项目需求变更的管理》。

很不幸，我们这次实验（两个小组独立开发同一个实际项目，分别采用传统开发流程和TDD）依然没有很好地控制变更。虽然两个组共享了一个额外的人来集中管理需求的变更，而且需求变更很少，最后还是出现了小规模的混乱，比如说需求文档和界面说明文档版本的不一致。

能有一个实用的工具来辅助变更控制，自然最好不过，可惜我在这方面的经验尚不能提供很好的帮助。初步的调查，也未能找出很好开源或者商用的工具能马上应用。

Hansky Butterfly是一套流程管理系统，提供了一整套支持软件开发过程的变更管理流程。同Hansky其它一样，都是收费的，下载了一个试用版，还没来得及使用。“Butterfly预置了“软件变更管理”解决方案，帮助企业管理软件项目开发过程中无处不在的变更。”商用的产品应该还是比较成熟的。

有一个企业级开源内容管理系统Plone，看其描述很是强大。

“Plone是Zope上的一个用户界面友好、功能强大的内容管理系统。Plone适合用作内部网/外部网的服务器、文档发布系统、门户服务器和异地协同的群件工具。Plone被eWeek杂志评定为2004年度10个最佳产品; InformationWeek则评论Plone是一个世界级的内容管理系统。同时，冠群公司(CA)也将Plone列为首批开放源代码资助项目之一，并在Plone基金会中占有董事席位。

Plone拥有丰富的扩展产品，包括论坛、Blog、Wiki、投票、问卷、考试、Portlet、版本管理、邮件列表等。

Plone基于发展多年的web应用服务器Zope和内容管理框架CMF。

Plone拥有强大的特性，包括易用、灵活的工作流引擎，能够对用户进行分组管理，还可以对内容的元数据、皮肤、文本格式转换、评注及讨论等进行管理。”

其实看好的是它的强大和流程定制功能（见上图的workflow），能否定制成一个需求变更管理系统，尚待进一步探索。

另外，自己也有一个idea，开发一个简单实用的web应用，来统一管理变更。就象Bugzilla这样，功能其实不用太强大，界面不需要太美观；重要的是，能解决这样繁琐的问题。再说，一直都使用了这么的开源软件，能自己也提供一个，很高兴。现在，国内也有不少个人和组织在sourceforge上申请了project，也有一些网站提供了开源的空间。在进一步地调查变更管理后，我想就会把这个idea付诸实践了。

4、构建管理

ANT几乎成了Java默认的构建工具，但要编写ANT的脚本还是很麻烦，即使能有现成只需要copy过来，也还是需要修改成本项目需要的。于是，出现了Maven。借用《JUnit in Action》这本书中话来描述ANT和Maven：“如果说ANT是一个构建工具，Maven就是一个构建环境”。“Maven可以增强脚本的复用。”关于Maven和Ant更详细的比较可以来看一篇blog《maven 和 ant 的比较》。

ANT是用过的最好的Build工具，而XP的核心实践——持续集成还需要另外的工具。CruiseControl 则是一个开源的持续集成框架。CruiseControl能够不断的进行builds，并且发布结果，并且能够在出现错误或者运行正常的时候，发出即时通告。关于CruiseControl的应用可以参考《浅谈CruiseControl的部署》。

关于持续集成，Martin Fowler有专文讨论，看这里。其中说到“集成越频繁，效果越好”，其实实践中会遇到一个问题：频繁的集成有没有必要。更多的情况是，每次的check in并不能给整体造成很大的影响，为什么还要耗费时间去集成？所以我们最后采用的是每日构建来取代持续的集成。