版本

大版分支

在發(fā)布一個(gè)穩(wěn)定的版本后，我們會(huì)創(chuàng)建一個(gè)分支，這是因?yàn)槲覀兊娜肆€需要馬不停蹄的繼續(xù)開發(fā)大量的新版本功能（修改代碼），而客戶使用的是穩(wěn)定版本，但很難說不會(huì)有BUG，這個(gè)時(shí)候我們就可以在這個(gè)分支修改BUG，立即交付給客戶。創(chuàng)建一個(gè)分支是TFS和很多源代碼管理工具都自帶的功能，可惜很多人不知道，我就啰嗦一下。

在TFS的“源代碼管理資源管理器”中，找到你的產(chǎn)品單元目錄，例如MyProduct，右鍵，選擇“Branch 分支”，出現(xiàn)下面的畫面：

在“Target 目標(biāo)”的地方鍵入MyProduct-1.0，這樣，就在與MyProduct平級(jí)的目錄，建立了一個(gè)新目錄：MyProduct-1.0。由于之前已經(jīng)在1.0發(fā)版時(shí)打了標(biāo)簽，所以我這里選擇了這個(gè)標(biāo)簽。點(diǎn)擊OK后，你還需要實(shí)際的簽入才能生效。

建立一個(gè)平級(jí)的目錄的好處是，你可以像以前的工作方式一樣，把這個(gè)1.0看成一個(gè)新的產(chǎn)品單元，這樣之前定義的流程在分支情況下仍然適用。

當(dāng)真的需要修改BUG時(shí)，你需要到MyProduct-1.0下修訂這個(gè)BUG，測試并簽入代碼，與往常沒有什么不一樣，唯一的另外就是，通常這個(gè)BUG在當(dāng)前開發(fā)版本中（在這里例子就是MyProduct）也有，TFS提供了簡便的方法幫助你快速完成MyProduct上此BUG的修訂，可以在MyProduct-1.0/src目錄上點(diǎn)擊右鍵，選擇“Merge 合并”，出現(xiàn)下圖：

在“Source branch 源分支”中選擇穩(wěn)定版本（已經(jīng)修訂BUG的版本），在“Target branch 目標(biāo)分支”上選擇開發(fā)版本（未修訂Bug的版本），注意，一般我們選擇“Selected changesets 選擇變更集”，而不是“All changes up to a specific version 所有變更”，這樣就僅針對(duì)你這個(gè)bug修改進(jìn)行合并，點(diǎn)擊“Next 下一步”。

這里你能看見所有未合并的變更集，選擇你的變更集，然后下一步，最后完成。重新回到MyProduct對(duì)應(yīng)的MyCode所在目錄，你會(huì)發(fā)現(xiàn)TFS自動(dòng)簽出了這個(gè)文件：

如果你打開這個(gè)文件，可以看見你修訂BUG的代碼也合并進(jìn)去，你需要的是繼續(xù)在當(dāng)前MyProduct上完成編譯和測試，最后簽入即可。

這里僅僅是一個(gè)演示，分支與合并其實(shí)是一門蠻高深的學(xué)問，我這里就不細(xì)說，僅作為一個(gè)引子。

補(bǔ)丁

當(dāng)我們已經(jīng)修訂BUG并測試通過后，必然已經(jīng)更新了TFS上的bin目錄，我們可以根據(jù)比對(duì)歷史版本，來知道到底修改了哪些組件。

在bin目錄上點(diǎn)擊右鍵，選擇“View History 查看歷史”，在出現(xiàn)的歷史列表中，選擇兩個(gè)版本，然后點(diǎn)擊“Compare Folders 比較目錄”。最后出現(xiàn)這個(gè)清單：

這是手工操作的方法，我是不會(huì)這樣干的，我還是使用“項(xiàng)目工具”，首先看看目錄結(jié)構(gòu)：

你看見多了一個(gè)hotfixs目錄，下面的目錄名，其01是產(chǎn)品單元的編號(hào)，而119就是在TFS上的“Changeset 變更集”編號(hào)，“項(xiàng)目工具”總是檢測最后一個(gè)補(bǔ)丁的編號(hào)，并與最新的編號(hào)比較，就跟你上圖中手工處理一樣，獲取到清單后，工具就下載這些文件到一個(gè)臨時(shí)目錄，并使用安裝包制作工具創(chuàng)建一個(gè)補(bǔ)丁安裝程序。

可能你會(huì)說，并不是把最新的dll復(fù)制到客戶就能修正某個(gè)bug的，可能還需要修復(fù)數(shù)據(jù)庫的表結(jié)構(gòu)，甚至修復(fù)數(shù)據(jù)。是的，你說的沒有錯(cuò)，但這個(gè)流程我們不會(huì)把他設(shè)計(jì)到補(bǔ)丁工具上，而是

這些最新的組件其包含這些功能，這樣補(bǔ)丁的流程就簡單很多。

如果你的某個(gè)版本時(shí)間跨度很長，很可能積累了很多的補(bǔ)丁，要知道這些補(bǔ)丁是向前依賴的，不能說單獨(dú)安裝一個(gè)補(bǔ)丁。我建議你的產(chǎn)品設(shè)計(jì)一個(gè)在線更新的功能，這樣就不會(huì)那么痛苦了。另外一個(gè)常見的實(shí)踐是制作SP1這樣的較大補(bǔ)丁包，他實(shí)際上就是把一堆的補(bǔ)丁合并成一個(gè)大補(bǔ)丁，方便新客戶的安裝。

有幾點(diǎn)要切記，切記：

• 補(bǔ)丁盡量只包含BUG的修訂，不要包含新功能；
• 給新客戶的安裝包，是原版+SP的形式，而不是直接一個(gè)最新版本。

這些忠告直接關(guān)系你的管理成本，如果你要問我為什么？怎么說呢，好復(fù)雜，你看Windows都是這么干的，O(∩_∩)O哈哈~算是解釋嗎。

中版分支

我知道，你在看到上面的第一點(diǎn)忠告時(shí)已經(jīng)暴跳起來，

天啊，客戶怎么可能等上一兩年沒有一個(gè)新版本？

做，當(dāng)然做，不過我們換一種方法來做。

讓我們?cè)O(shè)想一下，如果你將新特性放在MyProduct_1.0源代碼中，就會(huì)出現(xiàn)一個(gè)問題，新特性的開發(fā)畢竟需要一個(gè)較長的編碼和測試周期，當(dāng)客戶想你反映一個(gè)BUG時(shí)，你雖然可以很快修訂這個(gè)BUG，但是你無法發(fā)布給客戶，因?yàn)槟愕慕M件包含了很多尚未測試完畢的新特性，這個(gè)非常糟糕。

我的方法是，創(chuàng)建一個(gè)特性包分支，參加下圖

在完成1.0的發(fā)版后，會(huì)產(chǎn)生分支，這個(gè)我們上面已經(jīng)講過，并且在修正1.0的BUG后合并到開發(fā)版中，形成1.0.1版本。

在完成1.0分支后我們就開展了2.0的大規(guī)模開發(fā)，但我們會(huì)優(yōu)先開發(fā)R1的功能，在完成R1的開發(fā)和測試后，即1.1.1后，我們?cè)俅萎a(chǎn)生MyProduct-1.0 R1的分支，因?yàn)檫@個(gè)版本還包含了R1不需要的一些代碼（開發(fā)版不可能完全遵照R1的要求開發(fā)，可能更進(jìn)一步），所以我們需要花一些時(shí)間調(diào)整和測試。

在此期間，如果在正式版發(fā)現(xiàn)的BUG仍然需要合并到開發(fā)版，但是無需合并到R1版本，因?yàn)槲覀兒芸炀鸵呀?jīng)將就緒的R1合并到正式版，然后封存R1這個(gè)分支，這樣我們就僅維護(hù)兩個(gè)版本。在日后的開發(fā)中，如果再次修訂BUG，你應(yīng)該選擇合并對(duì)應(yīng)的變更集，這是因?yàn)檎桨嬉呀?jīng)包含很多的R1代碼，如果選擇全部合并，會(huì)把R1的代碼也合并過來，而此功能在開發(fā)版已經(jīng)包括了。

特性包

事實(shí)上，中版的分支方式我是不喜歡的，因?yàn)椴还躎FS的分支與合并功能再好，我們也還是需要維護(hù)多套源碼，一個(gè)BUG在多處修訂容易，每處都要測試就不輕松了，這都是“成本”。

我更喜歡“特性包”這樣的方式。特性包的案例你可以想象是Word這樣的軟件，當(dāng)Word開發(fā)完畢后，二次開發(fā)商利用提供的VSTO開發(fā)新的特性，二次開發(fā)商并沒有修改Word的源代碼，他們的代碼也沒有重疊，什么地方出現(xiàn)BUG就在什么產(chǎn)品單元上修改即可?；剡^來看我們的中版開發(fā)，你可以認(rèn)為這個(gè)二次開發(fā)商就是自己。

特性包的做法前提是你的產(chǎn)品具有較強(qiáng)的二次開發(fā)能力，當(dāng)開發(fā)完畢1.0后，并不立即產(chǎn)生分支，所有的中版開發(fā)放在一個(gè)獨(dú)立的產(chǎn)品單元，注意這個(gè)產(chǎn)品單元并不是一個(gè)分支，更不是一份拷貝的副本，而是基于1.0 SDK的二次開發(fā)。

從上圖可以看出，所謂特性版本就是一個(gè)獨(dú)立的產(chǎn)品單元，各自維護(hù)自己的BUG。但是這樣做對(duì)基礎(chǔ)產(chǎn)品的要求就比較高，要能在不改動(dòng)基礎(chǔ)產(chǎn)品的情況下，完成很多的增強(qiáng)特性。當(dāng)然，人無完人，產(chǎn)品也是，通常遇到不能支撐的時(shí)候，我們還是適當(dāng)?shù)男薷牡讓?，但要保持兼容?/p>

開發(fā)2.0產(chǎn)品的方法是，首先從1.0產(chǎn)生分支出MyProduct_2.0，將各個(gè)特性版的二次開發(fā)代碼整合到這個(gè)分支，最終形成2.0版本。但這個(gè)時(shí)候顯然還是要維護(hù)2套版本，當(dāng)發(fā)布3.0時(shí)，需要維護(hù)3套版本。

另外一種比較極端的做法是，開發(fā)2.0仍然看成已有產(chǎn)品單元的再次二次開發(fā)，3.0也是。這種方法對(duì)底層平臺(tái)的要求更高，即特性版也能支撐二次開發(fā)。為提高性能，可以在特性版或各個(gè)補(bǔ)丁包安裝完畢后，執(zhí)行自動(dòng)整合任務(wù)，以便將分散的二次開發(fā)整合成一個(gè)產(chǎn)品，有點(diǎn)像編譯的過程。