定制 bugzilla 进行项目管理.docx

定制 bugzilla 进行项目管理.docx

《定制 bugzilla 进行项目管理.docx》由会员分享，可在线阅读，更多相关《定制 bugzilla 进行项目管理.docx（16页珍藏版）》请在冰点文库上搜索。

定制bugzilla进行项目管理

定制bugzilla进行项目管理

ApacheHarmony项目是IBM中国开发中心上海，近年来参加的一个开源项目。

在这个项目中我们使用了开源软件开发中普遍使用的缺陷跟踪系统——Bugzilla。

Bugzilla是一个开源的缺陷跟踪系统（Bug-TrackingSystem），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。

针对项目的特性，我们将Bugzilla做为整个项目开发过程中的唯一管理工具。

通过这种独特的使用方式，积累了一些经验，希望可以和广大开发人员一起分享。

ApacheHarmony开源项目的开发流程

ApacheHarmony的提案在2005年5月被Apache软件基金会（ASF）接受，并且按照ASF惯例成为一个孵化（incubator）项目。

作为一个开源项目，所有参与的开发者需要遵循一个不同于一般产品开发的开发流程。

在Harmony项目的主页上有一个链接 GetInvolved，点开这个链接，您可以看到参与该项目的一些基本规则。

项目由广大的开发者提供的很多不同的捐献（contribution）推动，捐献包括代码，文档，反馈意见。

该项目的一个主要特征是，希望所有的开发均发生在社区（透明性）。

Harmony项目提供了以下的基础设施保证了项目的透明性（图1）：

∙项目开发中产生的任何正式的想法和讨论均发表到harmony邮件组上。

∙任何非正式的讨论发表到网络上的#harmonyIRCchannel频道。

∙所有的项目源码由一个公共的svn服务器控制。

该服务器进行了严格的权限控制，以接受代码的捐赠。

∙新功能的提交，包括项目开发中产生的缺陷（bug）均会被提交到JIRA系统上，并且随后提交补丁。

最后由具有权限的开发者将这些补丁提交到svn服务器上。

∙其他的一些相关的文档和讨论发表在 wiki 系统上。

图1：

Harmony项目透明的开发流程

可以看到，在这个开发流程中，任何关于项目的想法或是讨论均发生在项目的邮件组上。

项目中所有代码包括文档等资产均通过提交补丁的形式，通过JIRA系统提交。

然后由committer将JIRA系统中的补丁安装到svn代码库中。

在我们的开发团队中，大部分人扮演的是Contributor的角色，负责的主要工作是：

∙在邮件组上讨论需要开发的内容，获取邮件组上其他开发人员的意见，形成一个设计决定。

∙根据邮件组上形成的设计决定，开发并提交补丁。

补丁是开发小组的主要产品，而bugzilla系统正是面向补丁设计的系统。

为了提高代码的质量，结合bugzilla系统提供的功能，开发小组在内部制定了一套自己的开发流程（图2）。

开发小组内部的开发流程

图2开发小组内部的开发流程

在这样一个流程中，小组成员被分为了两种角色，分别是开发者（DEV）和质量保证人（QA）。

开发者如果有任何代码需要提交到JIRA系统中，他的这些代码就需要先经过小组内部流程的检验。

开发者首先在bugzilla系统上新建一个bug报告（下文中将这种bug称为代码审查请求），将该bug的所有人（owner）设置为他自己，并将该bug分配给质量保证人（下文简称QA）。

这时代码审查请求的状态变为‘已分配’。

这时如果开发者满怀信心的觉得自己的代码已经相当优美，他就将自己的代码作为当前bug的附件，上传到bugzilla系统中。

当QA发现新的代码审查请求，他/她会按照特定的标准（代码和测试用例是否有逻辑错误，代码风格是否合适）进行代码审核。

如果没有发现任何问题，QA将代码审查请求的状态改为‘已解决’。

这表示代码通过审核，可以被提交到社区里去了。

当然一般来说，代码总会出现一些小的问题。

这时QA就会针对这些问题报告新的bug，并将这些bug分配给开发者。

这些bug不同于之前的代码审查请求，他们真正表示代码中的缺陷。

这些代码缺陷会阻塞住原先的代码审查请求（通过bugzilla提供的功能），保证如果这些缺陷不被修复（状态不转变为closed），则代码审查请求的状态就不能变为‘已修复’。

当QA认为所有的缺陷都已经找出来之后，他/她会将代码审查请求分配给开发者。

这时，开发者针对QA报告的缺陷，修正自己的代码，并提交新的代码补丁（将前一个代码补丁设置为废旧），将代码审查请求重新分配给QA。

这个过程将被重复，直到开发者提交的代码不会再被检查出缺陷为止。

下面的文章将结合上面介绍的流程，描述bugzilla的相应功能。

问题请求系统（RequestSystem）

鉴于Harmony项目的特性，对代码质量的要求非常严格，仅仅通过一些代码审查（Review）工具无法完全保证其质量，所以开发中除了实际的开发人员，还增加了QA（QualityAssurance）的角色来保证代码质量。

所有代码必须经过从开发人员到QA的反复检查才能发布。

Bugzilla为这个迭代过程提供了很好的支持。

问题请求系统允许开发人员为一个补丁设置标签（flag）来请求对当前代码的复查。

Bugzilla共提供了两种类型的标签，分别用来表示bug和补丁的状态，我们在开发中只使用了补丁的标签功能。

对于QA来说，他可以设置标签来表示接受或者拒绝这个补丁。

通过这个标签无论是开发人员或是QA都可以及时掌握一个补丁当前所处的状态。

以下我们详细展示如何通过Bugzilla的问题请求系统来进行代码开发的过程。

1.Bugzilla管理员安装完bugzilla系统后，为当前开发的项目新建一个复查标签（图3）。

图3管理标记类型

2.开发人员通过Eclipse的Subclipse插件生成基于当前服务器上代码的增量补丁，详见应用补丁部分。

3.开发人员在Bugzilla上新建一个优先级为“开发”类型的新记录（图4），作为本开发流程的基点。

图4提交Bug:

TestProduct

4.开发人员将补丁上传到“开发”记录的附件中（在附件中递交补丁将在后面介绍），并开启补丁的标签功能，比如开发人员张三与QA李四搭档开发，张三在设置标签的时候就会指定李四来复查，在下拉菜单中选中‘？

’，并在后面的字段填上李四（图5）。

图5标记

此时，补丁的状态字段就会显示为——zhangsan:

复查?

（lisi）（图6）。

如果开发人员重新想置空标签或者不指定具体的QA，只需在下拉菜单中选中空格即可。

图6标记为需要复查

5.对于QA来说，他可以利用标签的另外两个值来表明补丁的状态。

如果QA发现补丁中存在缺陷或者bug，就将标签置为‘-’，表示没有通过复查（图7）。

图7标记为拒绝

然后，针对补丁，报告bug（在bugzilla上创建优先级为“复查”的新记录来报告补丁的bug），并将它（们）指派给开发者张三。

同时，设置这条记录的阻塞（block）字段，将它置为代码审查请求记录的编号（图8）。

如果这里报的bug没有修复的话，代码审查请求记录是无法被关闭（closed）的。

图8阻塞记录

6.开发者修复了QA报告的bug之后，制作新版本的补丁文件上传。

7.QA查看新补丁是否仍存在问题，若确认无误，可以关闭“复查”记录（图9）。

图9关闭

8.QA重复上述过程，直到补丁中没有缺陷。

当李四认为复查已通过，便可将标签置为‘+’，表明补丁通过了复查，这时附件状态就会显示为——李四:

复查+。

然后，QA将相应的“开发”记录状态置为“已解决”，解决方案置为“修复”（图10），告诉committer这个补丁已经可以递交到服务器。

图10标记为已修复

9.最后，项目组内的committer会搜索所有已解决（Resolved）的“开发”记录，把通过的补丁递交到Harmony的服务器上，再关闭相应的“开发”记录。

对已经提交问题的通配符搜索

开发过程中，会产生大量的bug报告，如何从这些数据中获得我们需要的记录？

bugzilla提供了两种不同复杂度的搜索方式，第一种方式仅提供了状态、产品和关键字三个字段来进行搜索，它只能进行最基本的搜索功能，方便开发人员进行一些快速的搜索。

Bugzilla同时也提供了更为强大和全面的搜索功能，支持对搜索的定制。

无论是开发人员还是QA都可以针对自己关注的问题，选择相关的字段，设置搜索条件（图11）。

对于搜索的关键字，无需输入完整信息，系统会返回所有以该关键字为子串的匹配结果。

图11通配符搜索

Bugzilla的搜索还提供了一个非常有价值的功能，它可以保存每次的搜索配置，只要你为当前的搜索设置一个易记名字（图12），就能保存当前搜索配置供下次使用，省去了无谓琐碎的重复配置。

如果条件有变动，还能编辑搜索条件。

图12搜索结果

当需要重复相同的搜索时，无需再次设置搜索条件，只需点击保存的名字就可以获得同样的搜索结果（图13），为开发人员提供了巨大的便利。

图13保存搜索结果

开发中我们还可以通过RSS阅读器来订阅搜索结果，定制搜索条件获得数据时，在搜索的http地址后面加上"&ctype=rss"便可获取符合RSS标准的XML数据。

通过RSS客户端软件订阅，便可与数据保持同步，无需通过sendmail来通知最新的变化。

报表的生成

开发进行了一段时间后，项目经理需要对项目进展以及所有开发人员的工作状况进行汇总，bugzilla报表统计功能省去了枯燥的数据录入，方便汇总统计。

Bugzilla可以生成两种形式的报表（Report）进行统计。

一种是以表格的形式，这是默认支持的。

还有一种形式是通过直方图来表示结果，更加直观，它需要在编译bugzilla前，添加图形模块。

两种形式报表的生成过程大致相同，我们以表格形式生成项目汇总报告为例，来介绍该功能。

生成报表过程中条件的筛选类似高级搜索中搜索条件的定制。

Bugzilla报表生成功能提供了较大灵活性，用户可以设置三个坐标轴的字段值（图14）。

举简单的例子，我们开发总结时需要比较各个开发小组所有“开发”记录的总数，就可以通过如下方式来产生汇总数据

∙纵坐标：

选择报告人，即开发人员资料。

∙横坐标：

选择开发人员负责的项目组件。

然后在筛选条件的优先级中选择“开发”，如果想统计QA的工作，只需把优先级改为“复查”即可。

如果不想在同一张表格中生成数据，还可在“多表显示”中选择报告人，这样就会为每个开发人员生产一个表格。

图14生成表格形式的报表

补丁提交

开发中，补丁是通过附件的方式递交的（图15）。

图15提交补丁

1.点击创建新附件链接，转入建立新的附件页面（图16）。

2.输入附件的文件路径。

3.Bugzilla在服务器端提供两种附件的存放方式。

对于大文件，只在数据库中保存文件路径、文件名等定位信息，而把文件保存在本地的文件系统中，这样可减少数据库读写次数，增加效率。

对于小文件，bugzilla直接将文件写入数据库中。

为了减少复杂度，补丁一般都不会很大，只有在补丁特别大的时候，才有需要选择大文件（BigFile）选框。

4.补丁文件的描述，可以在这里简洁的介绍补丁添加的功能。

5.附件文件类型选择。

Bugzilla支持多种文件类型附件上传，系统能自动检测，用户也可以指定文件类型。

当选择了补丁框后，下面选择其他文件类型的输入框就会变成灰色，无需进行设置。

因为我们递交的附件都是补丁（patch）形式，所以只需选中补丁选框。

6.当不想公开补丁内容时，可选中隐私（Privacy）框。

7.如果想废弃原先递交的附件，可以在废弃（Obsoletes）中选择先前递交的某一附件。

8.由于补丁是分派给QA的，所以开发人员递交补丁时无需设置重新分派（Reassignment）。

9.为补丁设置复查标签，将复查标签的状态置为‘？

’，并在后面的输入框输入配对的QA用户名，指派对应的QA进行复查。

10.当补丁完成的任务比较复杂的时候，可以在注释（Comment）框中为补丁添加更加详细的介绍，这个选项是可选的。

图16添加补丁

开发中，如果安装bugzilla的时候添加了PatchReader模块（这个Perl模块是可选的），用户可在bugzilla中直接预览补丁内容,只要补丁是通过CVS或者Subversion生成。

点击区别（diff）链接，bugzilla便会自动生成补丁修改前后的对比页面。

（图17）。

图17查看补丁

使用eclipse应用补丁

在开发过程中，开发人员通过Subclipse（支持subversion操作的eclipse的插件）制作补丁，然后QA将其应用到eclipse运行，只有通过了所有的单元测试，补丁才能通过。

1.在eclipse的workspace点右键，选择Subclipse提供的Team菜单选项。

2.应用补丁（Applypatch）的方式有两种，一种是通过文件打补丁。

还可以直接打开补丁文件，然后将其内容复制到内存的剪贴板（Clipboard）中（图18），再从剪贴板中打补丁。

3.选中需要打补丁的项目。

4.选择让系统自动猜测（Guess）正确的目录层次，也可以通过忽略补丁路径靠前部分来手工调整（图19）。

图18应用补丁

图19验证补丁

系统的本地化

Bugzilla系统为本地化保留了开放的接口，只要提供符合规范的本地语言模板即可让你的bugzilla系统支持你的本地语言，在SourceForge上可以找到由第三方提供的模板支持，无需自行开发新的模板。

这个第三方库还提供了css脚本，可以定制自己界面，为更好的查看bug提供方便。

本地化bugzilla的过程非常方便，只需按照下面所示步骤即可：

1.从 SourceForge 下载工具包，解压。

2.从解压出来的两种编码方式中选一种模板（UTF8格式和GB2312格式）复制到%bugzilla根目录%/template/，并将文件夹改名为cn（默认英文模板名字en）。

3.以管理员身份登录系统，进入参数配置页面（图20）

4.将language改为cn（图21），系统便会自动去提取新加的模板来格式化界面，如果想重新恢复英文，只需重新改回en即可。

图20参数设置

图21本地化

参考资料

学习

∙“在Linux上使用Bugzilla跟踪bug”（developerWorks，2005年4月）给出了在Linux系统上安装Bugzilla的逐步指南。

∙了解使用Bugzilla的部分 公司、组织和项目（共394个），其中包括NASA、Apache、Eclipse、GlaxoSmithKline、Novell、SandiaLabs、W3C、Wikipedia和IBM。

∙ApacheHarmony官方网站：

http:

//incubator.apache.org/harmony/

∙阅读 进入Harmony世界 系列：

第1部分：

ApacheHarmony项目简介 、 第2部分：

研究PortLayer 和 第3部分:

HarmonyVMI。

∙如何参与Harmony：

http:

//incubator.apache.org/harmony/get-involved.html

∙Java技术专区：

这里有数百篇关于Java编程各个方面的文章。

获得产品和技术

∙访问 Bugzilla Web站点，下载最新版本的Bugzilla。

∙ApacheHarmony的二进制版本下载：

http:

//incubator.apache.org/harmony/downloads.html

∙IBMApacheHarmony开发包（VMEnvironment）：

讨论

∙developerWorksbolgs：

加入developerWorks社区。

∙