我的Subversion與Trac使用經驗

於每一個開發團隊而言,正確且順暢的溝通協調運作機制是不可或缺的,少了這些協同機制,就像在交響樂團裡的走調雜音,或像團體裡我行我素的獨行俠,都會使團隊戰力大打折扣,畢竟現今的軟體開發已經複雜到無法依賴單打獨鬥的曠世天才而能完成的。只要體認到開發不能只依靠少數人、必須群策群力、互相配合、遵循共同的流程規定,那麼像Tracking system、Version control system等就必然變成開發人員的好朋友,無法離開它們而能順利運作的了。

然而現實的狀況是:功能強大且完整的協同軟體不是每天在生存線上掙扎的台灣小軟體公司能用得起的,導入與使用費用之高都令人咋舌,因而導入Open source的工具再搭配部份自訂流程就變成不得不的選擇。我們最早的版本控制工具是微軟的Visual SourceSafe,但當開發團隊分散兩地時,Visual SourceSafe就陣亡了,雖然有第三方廠商的Source OffSite讓Visual SourceSafe能在Internet上使用,但所費不貲,最終才使用了CVS+WinCVS的組合,在CVS上我們開發了重要的產品和許多個大小專案,期間也是跌跌撞撞,歷經許多錯誤嘗試。

接著是Bug/Issue tracking system的導入,用以補足問題的自動追蹤功能與任務的線上分派。最早使用的是Track+,選用它的原因是它是以Java撰寫的,而Java正是我們的主力開發語言且2.X版時能下載程式碼,因而給了我們自行修改的機會(現在3.x版已經沒辦法修改原始碼了),再者Track+具備國際化(I18N)的能力,約在2003年我在珠海趁晚上和假日完成了繁體中文語言包,再經幾個小專案的測試後推動到所有專案。

CVS用了幾年後,因為Subversion提供更快速的存取與相容CVS的操作方式,在這兩三年裡就逐步由CVS+WinCVS轉移到Subversion+TortoiseSVN,轉移的策略是舊的專案或較少變動的專案就保留在CVS上,新的專案與更新頻繁的專案就移到Subversion上。而2007年又開始試用Trac,嘗試把Wiki、Tracking、Subversion整合在一起,以下是我們使用Trac的幾個試驗:

  • 在Wiki首頁放置一個公佈欄:PM、SA要公佈的開發事項以日期排序,以通知專案成員。以前大多是用E-Mail聯絡通知,但新成員是沒辦法看到的,全部放在Wiki上就不怕有疏漏的狀況。
  • 任務分派用Ticket發送:SA透過Trac分派給PG(Programmer)要撰寫的作業,開始日期與期望完成日期皆有紀錄,PG的作業狀況與績效都能追蹤考核。
  • 透過異動歷程了解開發活動:每天PM透過異動歷程能大致了解PG的進度與程式撰寫狀況。
  • 我們把Trac的Component存模組代碼,再增加模組報表,如此便能輕易地知道各個模組作業的完成進度。

Subversion則是所有文件與程式碼的統一窗口,所有專案成員皆以Subversion上的檔案為準,這樣以前用Mail寄來寄去,或透過File Server取檔導致版本不一致的問題就消弭於無形了。一般專案開發組織裡,我們尚有測試組的配置,當PG經由Trac通知測試人員開始測試時,測試人員由Subversion取出程式,在他的本地端編譯、測試,以確保測試的版本是正確、一致的,若有差錯也能立即被發現。

這裡再分享幾個推動上的小經驗。

  • 中文化是必須的:要能順利推動某個工具,一定要有中文介面,缺少中文介面一定都會大打折扣,且會給成員推拖的藉口。尤其是大陸同事,看到英文心就亂一半,要他們用非中文工具,簡直是比登天還難。
  • 要循序漸進、不可躁進:推行此類會影響作業流程的工具時,切忌一開始就全面推動,若不先經小範圍測試再逐步修改調整,可能對團隊帶來翻天覆地的混亂感受,從而增加推行失敗的機率。
  • 主管要堅持,成員要配合:導入初期的不適應,勢必引起反彈,但只要是對的政策就應該堅持,主管、成員都要敞開心胸,針對扞格不合之處做調整與修正,最終才能磨合成適合環境的較理想運作模式。

事實上,Tracking system與Version control system僅是專案運作的基本功而已,但這些基礎都無法運作順利,遑論其他更因人而異的管理機制了。從以上的推動描述可以看出我們對於推動新的流程與控管機制是抱持慎重其事的心態,因為一個機制的變更影響到的是許多聰明、又有想法的開發人員,最終還是要讓這些機制內化成每天的標準動作,而這樣的流程也才有執行的必要。

以上小小經驗與大家分享。

##

您可能也會有興趣的類似文章

簡睿

服務於軟體業的資訊老兵。興趣廣泛,學習力佳,樂於分享所知所學。

您可能也會喜歡…

4 個回應

  1. ys表示:

    也許可以考慮試試免費的CodeBeamer MR, 能由專案的角度來管理Subversion,又有每個專案的Tracker, 以及每個專案的Wiki頁
    http://www.intland.com/products/cb-mr/overview.html

  2. 部落小波表示:

    哇, jerry 兄好快就發文了, 看來以後可以常常邀稿可惜我會的不多, 不然也想多寫一些文章我用 Trac, MoinMoin, Perforce 已經有一段時間了, 雖然不是整合在一起的工具, 但是我已經感受到, 使用這些工具的用處我目前 issue tracking 做任務分派, wiki 當做 developer’s portal 保存組織知識 (記憶), Version Control 確保多需求同時被多人開發時的版本保存; 但是 1, 2 個人的 team 試推是都沒什麼問題, 但是推到整個單位的話, 因為有改變使用者習慣的問題, 大家都還是想用 word 寫文件, 那就失去 wiki 好用的 feature 了其他同事也有在 survey 一些商用的套裝軟體, 可是我個人覺得, 不但不便宜, 比起 open source 的工具也沒有好用到那去, 可是用 open source 的這些東西, 就缺了一點點的整合性於是乎在想, 真的用 rational 的工具, 就能把需求和 source code 的關聯管理的很好嗎 ?  工具應該都只能做到 issue -> source code changelist 的關聯, 真的要理想到想要瞭解這支程式會變動到什麼需求的管理, 用好的工具就能很簡單的管理了嗎 ???我目前是很土法, 先去找 perforce 的 changelist, 再去看這些 changelist 在 trac 的詳細描述, 不整合, 但是多少可以管理程式碼 和 需求的關聯

  1. 2008/12/10

    […] 前前後後用過的Wiki系統有:Python寫的Trac與通行在本機的WikidPad、只有一個HTML的本機TiddlyWiki與TiddlyWiki的網路版ccTiddly,最近想在主機空間上建立Wiki系統,以上的Wiki都不甚適用,因此Survey了幾個以PHP 4撰寫的Wiki系統:MediaWiki、DokuWiki與PmWiki,其中MediaWiki需要MySQL資料庫系統,後二者則都是儲存成檔案,不需要資料庫。 […]

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *