2006 年 10 月 26 日

     Apache Harmony 項目是 IBM 中國開發(fā)中心上海，近年來參加的一個開源項目。在這個項目中我們使用了開源軟件開發(fā)中普遍使用的缺陷跟蹤系統(tǒng) —— Bugzilla。Bugzilla 是一個開源的缺陷跟蹤系統(tǒng)（Bug-Tracking System），它可以治理軟件開發(fā)中缺陷的提交（new），修復（resolve），關(guān)閉（close）等整個生命周期。針對項目的特性，我們將 Bugzilla 做為整個項目開發(fā)過程中的唯一治理工具。通過這種獨特的使用方式，積累了一些經(jīng)驗，希望可以和廣大開發(fā)人員一起分享。

Apache Harmony 開源項目的開發(fā)流程

     Apache Harmony 的提案在 2005 年 5 月被 Apache 軟件基金會（ASF）接受，并且按照 ASF 慣例成為一個孵化（incubator）項目。作為一個開源項目，所有參與的開發(fā)者需要遵循一個不同于一般產(chǎn)品開發(fā)的開發(fā)流程。在 Harmony 項目的主頁上有一個鏈接 Get Involved，點開這個鏈接，您可以看到參與該項目的一些基本規(guī)則。

     項目由廣大的開發(fā)者提供的很多不同的捐獻（contribution）推動，捐獻包括代碼，文檔，反饋意見。該項目的一個主要特征是，希望所有的開發(fā)均發(fā)生在社區(qū)（透明性）。Harmony 項目提供了以下的基礎(chǔ)設(shè)施保證了項目的透明性（圖1）：

• 項目開發(fā)中產(chǎn)生的任何正式的想法和討論均發(fā)表到 harmony 郵件組上。
• 任何非正式的討論發(fā)表到 freenode.net 網(wǎng)絡(luò)上的 #harmony IRC channel 頻道。
• 所有的項目源碼由一個公共的 svn 服務(wù)器控制。該服務(wù)器進行了嚴格的權(quán)限控制，以接受代碼的捐贈。
• 新功能的提交，包括項目開發(fā)中產(chǎn)生的缺陷（bug）均會被提交到 JIRA 系統(tǒng)上，并且隨后提交補丁。最后由具有權(quán)限的開發(fā)者將這些補丁提交到 svn 服務(wù)器上。
• 其他的一些相關(guān)的文檔和討論發(fā)表在 wiki 系統(tǒng)上。

     可以看到，在這個開發(fā)流程中，任何關(guān)于項目的想法或是討論均發(fā)生在項目的郵件組上。項目中所有代碼包括文檔等資產(chǎn)均通過提交補丁的形式，通過 JIRA 系統(tǒng)提交。然后由 committer 將 JIRA 系統(tǒng)中的補丁安裝到 svn 代碼庫中。

在我們的開發(fā)團隊中，大部分人扮演的是 Contributor 的角色，負責的主要工作是：

• 在郵件組上討論需要開發(fā)的內(nèi)容，獲取郵件組上其他開發(fā)人員的意見，形成一個設(shè)計決定。
• 根據(jù)郵件組上形成的設(shè)計決定，開發(fā)并提交補丁。

     補丁是開發(fā)小組的主要產(chǎn)品，而 bugzilla 系統(tǒng)正是面向補丁設(shè)計的系統(tǒng)。為了提高代碼的質(zhì)量，結(jié)合 bugzilla 系統(tǒng)提供的功能，開發(fā)小組在內(nèi)部制定了一套自己的開發(fā)流程（圖2）。

開發(fā)小組內(nèi)部的開發(fā)流程

     在這樣一個流程中，小組成員被分為了兩種角色，分別是開發(fā)者（DEV）和質(zhì)量保證人（QA）。開發(fā)者假如有任何代碼需要提交到 JIRA 系統(tǒng)中，他的這些代碼就需要先經(jīng)過小組內(nèi)部流程的檢驗。開發(fā)者首先在 bugzilla 系統(tǒng)上新建一個 bug 報告（下文中將這種 bug 稱為代碼審查請求），將該 bug 的所有人（owner）設(shè)置為他自己，并將該 bug 分配給質(zhì)量保證人（下文簡稱 QA）。這時代碼審查請求的狀態(tài)變?yōu)?‘已分配’。這時假如開發(fā)者滿懷信心的覺得自己的代碼已經(jīng)相當美麗，他就將自己的代碼作為當前 bug 的附件，上傳到 bugzilla 系統(tǒng)中。當 QA 發(fā)現(xiàn)新的代碼審查請求，他/她會按照特定的標準（代碼和測試用例是否有邏輯錯誤，代碼風格是否合適）進行代碼審核。假如沒有發(fā)現(xiàn)任何問題，QA 將代碼審查請求的狀態(tài)改為 ‘已解決’。這表示代碼通過審核，可以被提交到社區(qū)里去了。

     當然一般來說，代碼總會出現(xiàn)一些小的問題。這時 QA 就會針對這些問題報告新的 bug，并將這些 bug 分配給開發(fā)者。這些 bug 不同于之前的代碼審查請求，他們真正表示代碼中的缺陷。這些代碼缺陷會阻塞住原先的代碼審查請求（通過 bugzilla 提供的功能），保證假如這些缺陷不被修復（狀態(tài)不轉(zhuǎn)變?yōu)?closed），則代碼審查請求的狀態(tài)就不能變?yōu)?‘已修復’。當 QA 認為所有的缺陷都已經(jīng)找出來之后，他/她會將代碼審查請求分配給開發(fā)者。這時，開發(fā)者針對 QA 報告的缺陷，修正自己的代碼，并提交新的代碼補丁（將前一個代碼補丁設(shè)置為廢舊），將代碼審查請求重新分配給 QA。這個過程將被重復，直到開發(fā)者提交的代碼不會再被檢查出缺陷為止。