定制 bugzilla 進行項目管理

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 系統上。

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

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

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

補丁是開發小組的主要產品，而 bugzilla 系統正是面向補丁設計的系統。為了提高代碼的質量，結合 bugzilla 系統提供的功能，開發小組在內部制定了一套自己的開發流程（圖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）。

2. 開發人員通過 Eclipse 的 Subclipse 插件生成基于當前服務器上代碼的增量補丁，詳見應用補丁部分。

3. 開發人員在 Bugzilla 上新建一個優先級為“開發”類型的新記錄（圖4），作為本開發流程的基點。

4. 開發人員將補丁上傳到“開發”記錄的附件中（在附件中遞交補丁將在后面介紹），并開啟補丁的標簽功能，比如開發人員張三與 QA 李四搭檔開發，張三在設置標簽的時候就會指定李四來復查，在下拉菜單中選中‘？’，并在后面的字段填上李四（圖5）。

此時，補丁的狀態字段就會顯示為 —— zhangsan:復查?(lisi)（圖6）。如果開發人員重新想置空標簽或者不指定具體的 QA，只需在下拉菜單中選中空格即可。

5. 對于 QA 來說，他可以利用標簽的另外兩個值來表明補丁的狀態。如果 QA 發現補丁中存在缺陷或者 bug，就將標簽置為‘-’，表示沒有通過復查（圖7）。

然后，針對補丁，報告 bug（在 bugzilla 上創建優先級為“復查”的新記錄來報告補丁的 bug），并將它（們）指派給開發者張三。同時，設置這條記錄的阻塞（block）字段，將它置為代碼審查請求記錄的編號（圖8）。如果這里報的 bug 沒有修復的話，代碼審查請求記錄是無法被關閉（closed）的。

6. 開發者修復了 QA 報告的 bug 之后，制作新版本的補丁文件上傳。

7. QA 查看新補丁是否仍存在問題，若確認無誤，可以關閉“復查”記錄（圖9）。

8. QA 重復上述過程，直到補丁中沒有缺陷。當李四認為復查已通過，便可將標簽置為‘+’，表明補丁通過了復查，這時附件狀態就會顯示為——李四:復查+。然后，QA 將相應的“開發”記錄狀態置為“已解決”，解決方案置為“修復”（圖10），告訴 committer 這個補丁已經可以遞交到服務器。

9. 最后，項目組內的 committer 會搜索所有已解決（Resolved）的“開發”記錄，把通過的補丁遞交到 Harmony 的服務器上，再關閉相應的“開發”記錄。

回頁首

對已經提交問題的通配符搜索

開發過程中，會產生大量的 bug 報告，如何從這些數據中獲得我們需要的記錄？bugzilla 提供了兩種不同復雜度的搜索方式，第一種方式僅提供了狀態、產品和關鍵字三個字段來進行搜索，它只能進行最基本的搜索功能，方便開發人員進行一些快速的搜索。Bugzilla 同時也提供了更為強大和全面的搜索功能，支持對搜索的定制。無論是開發人員還是 QA 都可以針對自己關注的問題，選擇相關的字段，設置搜索條件（圖11）。對于搜索的關鍵字，無需輸入完整信息，系統會返回所有以該關鍵字為子串的匹配結果。

Bugzilla 的搜索還提供了一個非常有價值的功能，它可以保存每次的搜索配置，只要你為當前的搜索設置一個易記名字（圖12），就能保存當前搜索配置供下次使用，省去了無謂瑣碎的重復配置。如果條件有變動，還能編輯搜索條件。

當需要重復相同的搜索時，無需再次設置搜索條件，只需點擊保存的名字就可以獲得同樣的搜索結果（圖13），為開發人員提供了巨大的便利。

開發中我們還可以通過 RSS 閱讀器來訂閱搜索結果，定制搜索條件獲得數據時，在搜索的 http 地址后面加上"&ctype=rss"便可獲取符合 RSS 標準的 XML 數據。通過 RSS 客戶端軟件訂閱，便可與數據保持同步，無需通過 sendmail 來通知最新的變化。

回頁首

報表的生成

開發進行了一段時間后，項目經理需要對項目進展以及所有開發人員的工作狀況進行匯總，bugzilla 報表統計功能省去了枯燥的數據錄入，方便匯總統計。Bugzilla 可以生成兩種形式的報表（Report）進行統計。一種是以表格的形式，這是默認支持的。還有一種形式是通過直方圖來表示結果，更加直觀，它需要在編譯 bugzilla 前，添加圖形模塊。兩種形式報表的生成過程大致相同，我們以表格形式生成項目匯總報告為例，來介紹該功能。生成報表過程中條件的篩選類似高級搜索中搜索條件的定制。Bugzilla 報表生成功能提供了較大靈活性，用戶可以設置三個坐標軸的字段值（圖14）。

舉簡單的例子，我們開發總結時需要比較各個開發小組所有“開發”記錄的總數，就可以通過如下方式來產生匯總數據

• 縱坐標：選擇報告人，即開發人員資料。
• 橫坐標：選擇開發人員負責的項目組件。

然后在篩選條件的優先級中選擇“開發”，如果想統計 QA 的工作，只需把優先級改為“復查”即可。如果不想在同一張表格中生成數據，還可在“多表顯示”中選擇報告人，這樣就會為每個開發人員生產一個表格。

回頁首

補丁提交

開發中，補丁是通過附件的方式遞交的（圖15）。

1. 點擊創建新附件鏈接，轉入建立新的附件頁面（圖16）。
2. 輸入附件的文件路徑。
3. Bugzilla 在服務器端提供兩種附件的存放方式。對于大文件，只在數據庫中保存文件路徑、文件名等定位信息，而把文件保存在本地的文件系統中，這樣可減少數據庫讀寫次數，增加效率。對于小文件，bugzilla 直接將文件寫入數據庫中。為了減少復雜度，補丁一般都不會很大，只有在補丁特別大的時候，才有需要選擇大文件（BigFile）選框。
4. 補丁文件的描述，可以在這里簡潔的介紹補丁添加的功能。
5. 附件文件類型選擇。Bugzilla 支持多種文件類型附件上傳，系統能自動檢測，用戶也可以指定文件類型。當選擇了補丁框后，下面選擇其他文件類型的輸入框就會變成灰色，無需進行設置。因為我們遞交的附件都是補?。╬atch）形式，所以只需選中補丁選框。
6. 當不想公開補丁內容時，可選中隱私（Privacy）框。
7. 如果想廢棄原先遞交的附件，可以在廢棄（Obsoletes）中選擇先前遞交的某一附件。
8. 由于補丁是分派給 QA 的，所以開發人員遞交補丁時無需設置重新分派（Reassignment）。
9. 為補丁設置復查標簽，將復查標簽的狀態置為‘？’，并在后面的輸入框輸入配對的 QA 用戶名，指派對應的 QA 進行復查。
10. 當補丁完成的任務比較復雜的時候，可以在注釋（Comment）框中為補丁添加更加詳細的介紹，這個選項是可選的。

開發中，如果安裝 bugzilla 的時候添加了 PatchReader 模塊（這個 Perl 模塊是可選的），用戶可在 bugzilla 中直接預覽補丁內容,只要補丁是通過 CVS 或者 Subversion 生成。點擊區別（diff）鏈接，bugzilla 便會自動生成補丁修改前后的對比頁面。（圖17）。

回頁首

使用 eclipse 應用補丁

在開發過程中，開發人員通過 Subclipse（支持 subversion 操作的 eclipse 的插件）制作補丁，然后 QA 將其應用到 eclipse 運行，只有通過了所有的單元測試，補丁才能通過。

1. 在 eclipse 的 workspace 點右鍵，選擇 Subclipse 提供的 Team 菜單選項。
2. 應用補?。ˋpply patch）的方式有兩種，一種是通過文件打補丁。還可以直接打開補丁文件，然后將其內容復制到內存的剪貼板（Clipboard）中（圖18），再從剪貼板中打補丁。
3. 選中需要打補丁的項目。
4. 選擇讓系統自動猜測（Guess）正確的目錄層次，也可以通過忽略補丁路徑靠前部分來手工調整（圖19）。

回頁首

系統的本地化

Bugzilla 系統為本地化保留了開放的接口，只要提供符合規范的本地語言模板即可讓你的 bugzilla 系統支持你的本地語言，在 SourceForge 上可以找到由第三方提供的模板支持，無需自行開發新的模板。這個第三方庫還提供了 css 腳本，可以定制自己界面，為更好的查看 bug 提供方便。本地化 bugzilla 的過程非常方便，只需按照下面所示步驟即可：

1. 從 SourceForge 下載工具包，解壓。
2. 從解壓出來的兩種編碼方式中選一種模板（UTF8 格式和 GB2312 格式）復制到 %bugzilla 根目錄 %/template/，并將文件夾改名為 cn（默認英文模板名字 en）。
3. 以管理員身份登錄系統，進入參數配置頁面（圖20）
4. 將 language 改為 cn（圖21），系統便會自動去提取新加的模板來格式化界面，如果想重新恢復英文，只需重新改回 en 即可。

原文轉自：http://www.anti-gravitydesign.com