XP项目配置管理（2）——配置管理系统篇
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的比较。
|
|
Gnats |
Bugzilla |
Mantis |
Bugzero |
|
Description |
c and file based, unix only, opensource |
Perl and MySQL based, best on unix, opensource |
Php, mysql, Windows,linux |
Java/J2EE and database based, cross-platform |
|
Installation |
install gnatsd. configure gnatsd. install a gui front. some perl module |
install MySQL database. install perl many perl modules install Bugzilla with perl |
install php,MySQL database. IIS or apache,unzip Mantis to web root |
Java (jdk1.3+). any database any servlet engine. setup (gui-based) |
|
Administration
|
configured by editing some configuration files |
UNIX or Perl skills |
Php skills |
Java/J2EE experience |
|
Advantage |
Base on file,more reliable |
TimeTracking Reporting |
simple |
Pure java |
|
Disadvantage |
restricted |
complicated |
restricted |
Non-free |
最后选用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 (
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并不能给整体造成很大的影响，为什么还要耗费时间去集成？所以我们最后采用的是每日构建来取代持续的集成。
posted on 2005-09-20 17:00 Mark Jiao 阅读(2747) 评论(8) 编辑 收藏 举报
