定制 bugzilla 进行项目管理

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 开发小组内部的开发流程

 

     在这样一个流程中，小组成员被分为了两种角色，分别是开发者（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 提交补丁

 

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 查看补丁