- 1、本文档共19页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
定制 bugzilla 进行项目管理
Apache Harmony 项目是 IBM 中国开发中心上海,近年来参加的一个开源项目。在这个项目中我们使用了开源软件开发中普遍使用的缺陷跟踪系统 —— Bugzilla。Bugzilla 是一个开源的缺陷跟踪系统(Bug-Tracking System),它可以管理软件开发中缺陷的提交(new),修复(resolve),关闭(close)等整个生命周期。针对项目的特性,我们将 Bugzilla 做为整个项目开发过程中的唯一管理工具。通过这种独特的使用方式,积累了一些经验,希望可以和广大开发人员一起分享。
Apache Harmony 开源项目的开发流程
Apache Harmony 的提案在 2005 年 5 月被 Apache 软件基金会(ASF)接受,并且按照 ASF 惯例成为一个孵化(incubator)项目。作为一个开源项目,所有参与的开发者需要遵循一个不同于一般产品开发的开发流程。在 Harmony 项目的主页上有一个链接? HYPERLINK /harmony/get-involved.html Get Involved,点开这个链接,您可以看到参与该项目的一些基本规则。
项目由广大的开发者提供的很多不同的捐献(contribution)推动,捐献包括代码,文档,反馈意见。该项目的一个主要特征是,希望所有的开发均发生在社区(透明性)。Harmony 项目提供了以下的基础设施保证了项目的透明性(图1):
项目开发中产生的任何正式的想法和讨论均发表到 harmony 邮件组上。
任何非正式的讨论发表到 网络上的 #harmony IRC channel 频道。
所有的项目源码由一个公共的 svn 服务器控制。该服务器进行了严格的权限控制,以接受代码的捐赠。
新功能的提交,包括项目开发中产生的缺陷(bug)均会被提交到 JIRA 系统上,并且随后提交补丁。最后由具有权限的开发者将这些补丁提交到 svn 服务器上。
其他的一些相关的文档和讨论发表在? HYPERLINK /harmony/ 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。这个过程将被重复,直到开发者提交的代码不会再被检查出缺陷为止。
下面的文章将结合上面介绍的流程,描述 bug
文档评论(0)