定制 bugzilla 进行项目管理

　2008-01-05 08:34:55　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�

闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕濡ょ姷鍋涢ˇ鐢稿极閹剧粯鍋愰柟缁樺笧閳ь剦鍙冨鍝勑ч崶褏浠奸梺璇茬箲閼归箖鎮鹃悜钘夎摕闁靛濡囬崢鐢告⒑鐟欏嫷鍟忛柛鐘崇墵閵嗗倹绺介崨濠勫幈闁硅壈鎻槐鏇熺墡闂備線娼уú銈団偓姘嵆閻涱噣骞掑Δ鈧粻锝嗙節闂堟稑鏆欏ù婊堢畺閺岋綁濮€閳惰泛婀辨竟鏇熺節濮橆厾鍘甸梺缁樺姦閸撴岸鎮樻潏銊ょ箚闁圭粯甯炴晶娑氱磼缂佹ḿ娲寸€规洖宕灃闁告劕鍟犻崜婵堟崲濞戞ḿ鏆嗗┑鐘辫兌閺佹牜绱撴担浠嬪摵闁圭懓娲ら悾鐑藉箳閹搭厽鍍甸梺鐟板悁閻掞箓鎮楅幖浣光拻濞达絿鍎ら崵鈧梺鎼炲€栭悧鐘荤嵁韫囨稒鏅搁柨鐕傛嫹

婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繑銇勯幘鍗炵仼缂佺媭鍨堕弻娑㈠箛闂堟稒鐏堥悗鐟版啞缁诲啴濡甸崟顖氱閻庨潧鎽滈悾濂告⒑绾拋娼愭繛鑼枎椤繒绱掑Ο鑲╂嚌闂侀€炲苯澧畝锝堝劵椤︽煡鎮￠妶澶嬬厪闁割偅绻冮崑顏呯箾瀹割喕绨婚幆鐔兼⒑鐎圭姵銆冮柤鍐茬埣瀹曟繈鏁冮埀顒勨€旈崘顔嘉ч柛鈩冾殘閻熸劙姊洪悡搴℃毐闁绘牕銈稿畷鐑樼節閸パ冨祮闂侀潧楠忕槐鏇㈠储椤忓牊鈷戦柟鑲╁仜閸旀鏌￠崨顔锯姇缂佸倹甯熼ˇ瀵哥磼鏉堛劌绗氭繛鐓庣箻閸┾剝鎷呴柨瀣垫綗闂傚倷娴囧銊╂倿閿曞倸绠查柛銉墮閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柣鎴ｅГ閸ゅ嫰鏌ら崫銉︽毄濞寸姵姘ㄧ槐鎾诲磼濞嗘帒鍘＄紓渚囧櫘閸ㄥ爼濡撮崘顔煎窛闁哄鍨归崢娲倵楠炲灝鍔氭い锔诲灦瀹曪繝骞庨懞銉у帾闂婎偄娲﹀ú鏍ㄧ墡闂備浇顕х€垫帡宕滈悢濂夋綎闁惧繐婀辩壕鍏间繆椤栨碍鎯堟い顐㈢焸濮婅櫣鎷犻懠顒傤唹濠殿喗菧閸旀垿宕洪埀顒併亜閹哄秶顦﹂柛銈庡墴閺屾盯骞樼捄鐑樼€诲銈庡亜缁绘劗鍙呭銈呯箰鐎氼剟鎮楅鐑嗘富闁靛牆妫欑粈鈧梺鐟板暱闁帮絽鐣峰⿰鍕嚤閻庢稒菤閹锋椽姊绘笟鍥т簽闁稿鐩幊鐔碱敍濞戞瑦鐝峰銈嗘煥婢х晫澹曢悡搴唵閻犺櫣灏ㄩ崝鐔虹磼婢跺孩顏犻柍褜鍓氶鏍窗閺嶎厸鈧箓鏌ㄧ€ｂ晝绠氬┑顔界箓閻牆危閻戣姤鈷戠紒瀣儥閸庢劙鏌熼悷鐗堟悙閾荤偤鏌涢幇鈺佸Ψ婵℃彃鐗婄换娑㈠幢濡ゅ啰顔夊┑鐐茬墛閿曘垹顫忕紒妯诲濡炲绨肩憰鍡欑磽閸屾氨袦闁稿鎸荤换娑氣偓娑欋缚閻倝鏌涢幘璺烘灈鐎规洘妞介崺鈧い鎺嶉檷娴滄粓鏌熼悜妯虹仴闁逞屽墮缂嶅﹤顕ｉ幎绛嬫晢闁告洦鍓涢崢閬嶆煟鎼搭垳绉靛ù婊呭厴閻擃剟顢楅崒妤€浜鹃悷娆忓绾惧鏌涘Δ鈧崯鍧楊敋閿濆纾归柣鏇氱劍闉嬮梻鍌欑閹碱偄螞鐎靛摜涓嶉柟鎹愵嚙閽冪喖鏌曟繛鐐珕闁稿妫濋弻娑氫沪閸撗€妲堝銈呴獜閹凤拷

核心提示：2006 年 10 月 26 日 Apache Harmony 项目是 IBM 中国开发中心上海，近年来参加的一个开源项目，定制 bugzilla 进行项目管理，在这个项目中我们使用了开源软件开发中普遍使用的缺陷跟踪系统 —— Bugzilla，Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking Sy

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 项目透明的开发流程
定制 bugzilla 进行项目治理（图一）

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

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

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

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

开发小组内部的开发流程

图 2 开发小组内部的开发流程
定制 bugzilla 进行项目治理（图二）

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

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