Accurev 在大型專案使用版本管理工具

laofo · 2010年03月12日 · 4 次阅读

在大型專案使用版本管理工具

在微軟公司搞砸的所有事裡,視窗開發團隊使用版本管理的方式是得以倖免的項目之一。

一位年輕的視窗開發工程師寫道:

「...在重啟 Longhorn 專案之前,他們大約有七個分支(譯註:branches,是版本管理工具常會提供的功能之一,可以將目前管理的專案發展出多個支線,每個支線可各自發展,卻又保持有所關連。),然後大約每二或三週,將這些分支整合回主要分支上。現在,想像有數千個開發者將他們的程式碼直接提交(譯註:check in,將開發者修改的部分程式碼上傳到版本管理伺服器)到這七個分支上,會導致以下兩個狀況:

「1.你頻繁的提交程式碼,這很容易導致現有版本無法編譯,或者作業系統功能有問題;2.相反地,假若你沒有常常提交程式碼(這明顯是很糟糕的事),會讓你無法良好地回溯追蹤修改歷史。

「這明顯地不具有彈性。因此重啟專案之後,我們決定每個團隊應該要有他們自己的功能分支,每個「功能分區」(跨多個團隊)會再彙整成一個支線,最後整合成最終的主要支幹。(因此目前有上百個分支,分屬於大約六個支線之下)各團隊可自由地選擇他們需要的分支,並且可自由地決定上傳修改部分到支線的頻率。回歸整合(譯註:reverse-integration, RI,意思是將修改的內容彙整回主要支幹)需要通過多種品質鑑定,像是效能測試。視評量關卡的多寡而定,至少會花掉一天的時間來進行這整個流程,再加上一兩天的時間應付突發狀況,所以進行一次 RI 需要相當的成本。然而,這些評量關卡都是為了確保主要支幹上的產品的品質,如果沒有這些關卡,這套作業系統大概永遠無法推出。我認為這是那種「不會害死你」的交易 (譯:代價有點高但還是值得做)。

「有些團隊的確以用不健康的方式來進行專案,像是數個月才 RI 一次,但這是這些個別團隊的問題(或者說是他們的發佈管理),而不是流程的錯。一般來說,在品質方面越有紀律的團隊,其 RI 的頻率會更快更頻繁。從你獲得的系統元件穩定度/品質等級的變化資訊,可以輕易的推測出 RI 的速度等等,這是因為這些事情都是緊密的相連在一起。

在大型團隊中使用版本管理機制時,最佳的方法是依各高階功能分組,對個別的功能團隊創造出分支跟子分支。假若工具能支援,甚至可以讓每位開發人員有一個私有分支,這樣一來,他們就可以隨時提交到私有分支,直到自認程式碼穩定了才整合至團隊分支。QA 部門負責每次整合的合併點 (junction point)。亦即當開發人員將私有分支的內容整合回團隊的分支後,QA 就態盡快查驗,只有符合品質標準之後才能繼續往上整合。

還是一頭霧水嗎?看一下 Accurev 這套軟體的使用畫面吧,上頭有許多的「葉」分支,必須通過 QA 檢驗後功才能整合到更接近主線的分支。順便一提,Accurev 針對這種密集分支與整合的開發模式,做了一套很不錯的版本管理系統。Windows 開發團隊使用他們自己的版本管理系統,不過謠傳這其實是被買下原始碼版權的舊版 Perforce 系統。Perforce 在開發者間以昂貴穩固聞名,而且在處理超大型的程式碼庫時效率很高。

暂无回复。
需要 登录 后方可回复。