Using source control tools on huge projects 
在大型專案使用版本管理工具
Of all the things broken at Microsoft, the way they use source control on the Windows team is not one of them.
在微軟公司搞砸的所有事項裡，視窗開發團隊使用版本管理的方式是得以倖免於難的項目之一。
A young Windows engineer writes:
一位年輕的視窗開發工程師寫道：

"... prior to the restart effort of Longhorn, there were about seven [branches], reverse-integrating into one main branch every two or three weeks perhaps. Now, imagine several thousand developers checking in directly into seven branches. This will lead to two things:

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

"1. you check in frequently, and there's a very high chance of either breaking the build, or breaking functionality in the OS, or 2., as a counter-reaction, you don't check in very often, which clearly is bad, since now you don't have a good delta history of what you did.

「1.你頻繁的提交程式碼，這很容易導致現有版本無法編譯使用，或者系統內部分功能失效；2.相反地，假若你沒有常常提交程式碼（這明顯是很糟糕的事），會讓你無法良好地回溯追蹤修改歷史。

"So this clearly didn't scale. As part of the restart effort, we decided that each team would get its own feature branch, each feature area (multiple teams) would go up to an aggregation branch, and those would lead up to the final main branch. (As such there's now north of a hundred branches in tiers, leading up to about six aggregation branches.) Teams were free to choose how many sub-feature branches they wanted, if any, and they were free to choose how often they wanted to push up their changes to the aggregation branch. As part of the reverse-integration (RI, i.e. pushing up) process, various quality gates had to pass, including performance tests. Due to how comprehensive those gates ended up being, this would take at least a day to run, plus perhaps a day or two to triage issues if any cropped up; so there was a possibly considerable cost to doing an RI in the first place. However, these gates were essential in upholding the quality of the main branch, and had they not existed, the OS would have never shipped. I suppose it's one of those 'what doesn't kill you...' type deals.

「這明顯地不具有彈性。因此重啟專案之後，我們做的事情之一是：決定每個團隊應該要有他們自己的分支，每個「大功能項目」（或「多個團隊」）會再彙整成一個支線，最後整合成最終的主要支幹。（因此目前有上百個分支，分屬於大約六個支線之下）各團隊可自由地選擇他們需要的分支，並且可自由地決定上傳修改部分到支線的頻率。回歸整合（譯註：reverse-integration, RI,意思是將修改的內容彙整回主要支幹）需要通過多種品質鑑定，像是效能測試。由於需要通過各式各樣的評量關卡，至少會花掉一天的時間來進行這整個流程，加上還要保留一兩天的時間以應付突發的狀況，所以進行一次RI還需要考量許多額外的代價。然而，這些評量關卡都是為了確保主要支幹上的產品的品質，若是經由這些事來把關確認，則別想推出這系統。我認為這是屬於「那些不會傷害你的事」其中一種的約定。

"Some teams did manage to manufacture pathological cases for themselves where changes wouldn't RI up for several months, but that's the individual team's fault (or their release management), and not the process. Generally, the more disciplined teams were about quality, the faster and more frequently they'd RI. From what you know about the varying levels of stability/quality of components of the OS, it's pretty easy to map that back to RI velocity and so forth, since it all goes hand-in-hand pretty nicely.

「過去一些團隊採用不健康的方式來管理專案，像是數個月才RI一次，但這是這些團隊自己的問題（或者是他們管理機制的問題），而不是行程（譯註：process，用來規範專案開發程序的方法論）的錯。一般來說，對品質越有要求的團隊，其RI的頻率會更快更頻繁。從你獲得的系統元件穩定度/品質等級的變化資訊，可以輕易的推測出RI的速度和日後的變化，這是因為這些事情都是緊密的相連在一起。

When you're working with source control on a huge team, the best way to organize things is to create branches and sub-branches that correspond to your individual feature teams, down to a high level of granularity. If your tools support it, you can even have private branches for every developer. So they can check in as often as they want, only merging up when they feel that their code is stable. Your QA department owns the "junction points" above each merge. That is, as soon as a developer merges their private branch with their team branch, QA gets to look at it and they only merge it up if it meets their quality bar.
當你在大型專案上使用版本管理機制時，達成目標的最佳方法是採用功能性分組，對個別的團隊創造出分支跟子分支。假若你的工具支援，你甚至可以分派每位開發人員一個私有分支，這樣一來，他們就可以盡可能地維持版本管控，直到他們認為程式碼穩定了才提交。對每一次的版本整合，你的QA部門擁有統整的檢查點，亦即當開發人員將私有分支的內容整合回團隊的分支後，QA部門要盡快查驗，只有符合品管需求之後才允許繼續整合到更上層。
The best way to imagine this is to look at this screenshot from Accurev. As you can see there are a lot of "leaf" branches but as things get merged up towards the trunk, they have to pass through QA which basically just checks that it's OK and then merges it closer to the trunk. By the way, Accurev makes a nice source control system that is designed for this style of intensive branching and merging. The Windows team itself uses their own source control system which, it is rumoured, is just an old version of Perforce for which they bought a source license; Perforce has a reputation among developers for being expensive, solid, and extremely fast when working with extremely large source code bases.
還是一頭霧水嗎？看一下Accurev這套軟體的使用畫面吧，上頭有許多的子節點，當分支通過QA的檢驗之後便可以整合回每個支線上。另外，Accurev所推出的這個版本管理系統，專門被設計來處理具有這種分支與整合風格的開發系統。Windows開發團隊使用他們自己的版本管理系統，不過謠傳這系統其實是一個早期被買下軟體版權的Perforce系統。當使用在超大型的程式碼管控時，Perforce相當昂貴、穩固而且處理速度快，普遍獲得開發者好評。
<!-- Saved in parser cache with key wikidb-mw_:pcache:idhash:2500-0!1!0!!en!2 and timestamp 20070617103338 --> <!-- end content -->

------
林壽山
網站: http://superlevin.ifengyuan.tw
mail: superlevin@gmail.com