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

圖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 檢視補丁
 

使用 eclipse 應用補丁

在開發過程中，開發人員通過 Subclipse（支援 subversion 操作的 eclipse 的外掛）製作補丁，然後 QA 將其應用到 eclipse 執行，只有通過了所有的單元測試，補丁才能通過。

1. 在 eclipse 的 workspace 點右鍵，選擇 Subclipse 提供的 Team 選單選項。
2. 應用補丁（Apply patch）的方式有兩種，一種是通過檔案打補丁。還可以直接開啟補丁檔案，然後將其內容複製到記憶體的剪貼簿（Clipboard）中（圖18），再從剪貼簿中打補丁。
3. 選中需要打補丁的專案。
4. 選擇讓系統自動猜測（Guess）正確的目錄層次，也可以通過忽略補丁路徑靠前部分來手工調整（圖19）。

圖18 應用補丁


圖19 驗證補丁
 

系統的本地化

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

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

圖20 引數設定


圖21 本地化
 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-436087/，如需轉載，請註明出處，否則將追究法律責任。