定制 bugzilla 进行项目管理

Z时代
2024-01-10
分类：IT

2006 年 10 月 26 日

Apache Harmony 项目是 IBM 中国开发中心上海，近年来参加的一个开源项目。在这个项目中我们使用了开源软件开发中普遍使用的缺陷跟踪系统 —— Bugzilla。Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。针对项目的特性，我们将 Bugzilla 做为整个项目开发过程中的唯一管理工具。通过这种独特的使用方式，积累了一些经验，希望可以和广大开发人员一起分享。

Apache Harmony 开源项目的开发流程

Apache Harmony 的提案在 2005 年 5 月被 Apache 软件基金会（ASF）接受，并且按照 ASF 惯例成为一个孵化（incubator）项目。作为一个开源项目，所有参与的开发者需要遵循一个不同于一般产品开发的开发流程。在 Harmony 项目的主页上有一个链接 Get Involved，点开这个链接，您可以看到参与该项目的一些基本规则。

项目由广大的开发者提供的很多不同的捐献（contribution）推动，捐献包括代码，文档，反馈意见。该项目的一个主要特征是，希望所有的开发均发生在社区（透明性）。Harmony 项目提供了以下的基础设施保证了项目的透明性（图1）：

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

任何非正式的讨论发表到 freenode.net 网络上的 #harmony IRC channel 频道。

所有的项目源码由一个公共的 svn 服务器控制。该服务器进行了严格的权限控制，以接受代码的捐赠。

新功能的提交，包括项目开发中产生的缺陷（bug）均会被提交到 JIRA 系统上，并且随后提交补丁。最后由具有权限的开发者将这些补丁提交到 svn 服务器上。

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

图1：Harmony 项目透明的开发流程开发小组内部的开发流程

可以看到，在这个开发流程中，任何关于项目的想法或是讨论均发生在项目的邮件组上。项目中所有代码包括文档等资产均通过提交补丁的形式，通过 JIRA 系统提交。然后由 committer 将 JIRA 系统中的补丁安装到 svn 代码库中。

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

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

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

补丁是开发小组的主要产品，而 bugzilla 系统正是面向补丁设计的系统。为了提高代码的质量，结合 bugzilla 系统提供的功能，开发小组在内部制定了一套自己的开发流程（图2）。

开发小组内部的开发流程

图 2 开发小组内部的开发流程 Harmony 项目透明的开发流程

在这样一个流程中，小组成员被分为了两种角色，分别是开发者（DEV）和质量保证人（QA）。开发者如果有任何代码需要提交到 JIRA 系统中，他的这些代码就需要先经过小组内部流程的检验。开发者首先在 bugzilla 系统上新建一个 bug 报告（下文中将这种 bug 称为代码审查请求），将该 bug 的所有人（owner）设置为他自己，并将该 bug 分配给质量保证人（下文简称 QA）。这时代码审查请求的状态变为 ‘已分配’。这时如果开发者满怀信心的觉得自己的代码已经相当优美，他就将自己的代码作为当前 bug 的附件，上传到 bugzilla 系统中。当 QA 发现新的代码审查请求，他/她会按照特定的标准（代码和测试用例是否有逻辑错误，代码风格是否合适）进行代码审核。如果没有发现任何问题，QA 将代码审查请求的状态改为 ‘已解决’。这表示代码通过审核，可以被提交到社区里去了。

当然一般来说，代码总会出现一些小的问题。这时 QA 就会针对这些问题报告新的 bug，并将这些 bug 分配给开发者。这些 bug 不同于之前的代码审查请求，他们真正表示代码中的缺陷。这些代码缺陷会阻塞住原先的代码审查请求（通过 bugzilla 提供的功能），保证如果这些缺陷不被修复（状态不转变为 closed），则代码审查请求的状态就不能变为 ‘已修复’。当 QA 认为所有的缺陷都已经找出来之后，他/她会将代码审查请求分配给开发者。这时，开发者针对 QA 报告的缺陷，修正自己的代码，并提交新的代码补丁（将前一个代码补丁设置为废旧），将代码审查请求重新分配给 QA。这个过程将被重复，直到开发者提交的代码不会再被检查出缺陷为止。

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

问题请求系统（Request System）

鉴于 Harmony 项目的特性，对代码质量的要求非常严格，仅仅通过一些代码审查（Review）工具无法完全保证其质量，所以开发中除了实际的开发人员，还增加了QA（Quality Assurance）的角色来保证代码质量。所有代码必须经过从开发人员到 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 提交补丁

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

输入附件的文件路径。

Bugzilla 在服务器端提供两种附件的存放方式。对于大文件，只在数据库中保存文件路径、文件名等定位信息，而把文件保存在本地的文件系统中，这样可减少数据库读写次数，增加效率。对于小文件，bugzilla 直接将文件写入数据库中。为了减少复杂度，补丁一般都不会很大，只有在补丁特别大的时候，才有需要选择大文件（BigFile）选框。

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

附件文件类型选择。Bugzilla 支持多种文件类型附件上传，系统能自动检测，用户也可以指定文件类型。当选择了补丁框后，下面选择其他文件类型的输入框就会变成灰色，无需进行设置。因为我们递交的附件都是补丁（patch）形式，所以只需选中补丁选框。

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

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

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

为补丁设置复查标签，将复查标签的状态置为‘？’，并在后面的输入框输入配对的 QA 用户名，指派对应的 QA 进行复查。

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

图16 添加补丁

开发中，如果安装 bugzilla 的时候添加了 PatchReader 模块（这个 Perl 模块是可选的），用户可在 bugzilla 中直接预览补丁内容,只要补丁是通过 CVS 或者 Subversion 生成。点击区别（diff）链接，bugzilla 便会自动生成补丁修改前后的对比页面。（图17）。

图17 查看补丁

使用 eclipse 应用补丁

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

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

应用补丁（Apply patch）的方式有两种，一种是通过文件打补丁。还可以直接打开补丁文件，然后将其内容复制到内存的剪贴板（Clipboard）中（图18），再从剪贴板中打补丁。

选中需要打补丁的项目。

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

图18 应用补丁图19 验证补丁

系统的本地化

Bugzilla 系统为本地化保留了开放的接口，只要提供符合规范的本地语言模板即可让你的 bugzilla 系统支持你的本地语言，在 SourceForge 上可以找到由第三方提供的模板支持，无需自行开发新的模板。这个第三方库还提供了 css 脚本，可以定制自己界面，为更好的查看 bug 提供方便。本地化 bugzilla 的过程非常方便，只需按照下面所示步骤即可：