軟件源代碼版本管理與發(fā)布

1、軟件源代碼版本管理與發(fā)布版本號(hào):1.1文件編號(hào): XWQMS-CM-TEM-01 軟件源代碼版本管理與發(fā)布版本：1.0日期： 2010-9-9欣網(wǎng)視訊 | 天智互聯(lián) 修訂記錄日期版次描述作者審核批準(zhǔn)2010-9-91.0初版發(fā)布趙淵博目 錄修訂記錄21.引言41.1.目的41.2.術(shù)語(yǔ)41.3.參考資料52.軟件版本管理52.1.版本階段說(shuō)明52.2.版本命名規(guī)范52.3.版本號(hào)修改規(guī)則52.4.SVN版本庫(kù)分支與合并策略62.4.1.版本庫(kù)管理說(shuō)明62.4.2.版本庫(kù)操作說(shuō)明62.4.3.各種源碼變動(dòng)時(shí)，版本庫(kù)操作方案72.4.4.版本庫(kù)發(fā)布模式92.5.版本號(hào)發(fā)布132.5.1.版本發(fā)布追

2、蹤表13欣網(wǎng)視訊 | 天智互聯(lián)第 13 頁(yè) 共 13 頁(yè)1. 引言1.1. 目的該文檔是配置管理計(jì)劃的一部分，主要用于源代碼版本管理與發(fā)布。也可用于項(xiàng)目配置管理與發(fā)布。該文檔使項(xiàng)目組成員熟悉并按文檔約定執(zhí)行版本管理與發(fā)布。該文檔列舉在開發(fā)過(guò)程中會(huì)出現(xiàn)的開發(fā)情況，規(guī)范在開發(fā)過(guò)程中分支的類型，何時(shí)分支、何時(shí)合并。該文檔根據(jù)實(shí)際項(xiàng)目操作實(shí)踐處于不斷完善中。應(yīng)該此方案最基本的前提是需要熟悉SVN客戶端操作。1.2. 術(shù)語(yǔ)名稱解釋備注SvnSubversion的縮寫，版本控制管理工具TsvntortoiseSVN的縮寫，版本控制管理工具的客戶端修訂版本(revision)每一次提交修改到版本庫(kù)，就會(huì)使版

3、本庫(kù)進(jìn)入一個(gè)新的狀態(tài)，稱之為修訂版本。每一個(gè)修訂版本都會(huì)被賦予一個(gè)唯一的，比前一個(gè)修訂版本號(hào)大一的自然數(shù)。一個(gè)新建立的版本庫(kù)的修訂版號(hào)為0，其中除了空的根目錄外，什么都沒有。版本庫(kù)（Repository）存放修訂版的數(shù)據(jù)庫(kù)本地工作拷貝（Local working copy）修訂版在本地的副本版本的檢入（Check in）本地副本提交到服務(wù)器的版本庫(kù)檢出（Check out）從服務(wù)器的版本庫(kù)中取出修訂版成為本地副本標(biāo)簽（Tags）為某一日期的版本加一個(gè)名字，便于檢出或發(fā)布分支（Branches）修訂版打分支，以后可以平行修改，互不干擾合并（Merging）將分支的修訂版合并為一個(gè)新的修訂版沖突（

4、Conflict）并發(fā)版本控制時(shí)防止修訂版混亂的錯(cuò)誤機(jī)制1.3. 參考資料Version Control with SubversionSMOP文檔格式定義規(guī)范2. 軟件版本管理2.1. 版本階段說(shuō)明* Alpha版: 此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主，通常只在軟件開發(fā)者內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。* Beta版: 該版本相對(duì)于版已有了很大的改進(jìn)，消除了嚴(yán)重的錯(cuò)誤，但還是存在著一些缺陷，需要經(jīng)過(guò)多次測(cè)試來(lái)進(jìn)一步消除，此版本主要的修改對(duì)像是軟件的UI。* RC版: 該版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯(cuò)誤的BUG，與即將發(fā)行的正式版相差無(wú)幾。* R

5、elease版: 該版本意味“最終版本”，在前面版本的一系列測(cè)試版之后，終歸會(huì)有一個(gè)正式版本，是最終交付用戶使用的一個(gè)版本。該版本有時(shí)也稱為標(biāo)準(zhǔn)版。一般情況下，Release不會(huì)以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號(hào)(R)。2.2. 版本命名規(guī)范軟件版本號(hào)由四部分組成，第一個(gè)1為主版本號(hào)，第二個(gè)1為子版本號(hào)，第三個(gè)1為階段版本號(hào)，第四部分為日期版本號(hào)+希臘字母版本號(hào)+SVN最后修訂版本號(hào)，希臘字母版本號(hào)共有5種，分別為：base、alpha、beta、RC、release。例如：1.1.1.20100409_beta_334。2.3. 版本號(hào)修改規(guī)則主版本號(hào)(1)：當(dāng)功能模塊有較大的變動(dòng)

6、，比如增加多個(gè)模塊或者整體架構(gòu)發(fā)生變化。此版本號(hào)由項(xiàng)目經(jīng)理和技術(shù)主管決定是否修改。* 子版本號(hào)(1)：當(dāng)功能有一定的增加或變化，比如增加了對(duì)權(quán)限控制、增加自定義視圖等功能。此版本號(hào)由項(xiàng)目經(jīng)理和技術(shù)主管決定是否修改。* 階段版本號(hào)(1)：一般是 Bug 修復(fù)或是一些小的變動(dòng)，要經(jīng)常發(fā)布修訂版，時(shí)間間隔不限，修復(fù)一個(gè)嚴(yán)重的bug即可發(fā)布一個(gè)修訂版。此版本號(hào)由技術(shù)主管決定是否修改。* 日期版本號(hào) (20100409):用于記錄修改項(xiàng)目的當(dāng)前日期，每天對(duì)項(xiàng)目的修改都需要更改日期版本號(hào)。此版本號(hào)由開發(fā)人員決定是否修改。* 希臘字母版本號(hào)+SVN最后修訂版本號(hào)(beta_334):此版本號(hào)用于標(biāo)注當(dāng)前版本

7、的軟件處于哪個(gè)開發(fā)階段，當(dāng)軟件進(jìn)入到另一個(gè)階段時(shí)需要修改此版本號(hào)。此版本號(hào)由項(xiàng)目決定是否修改。2.4. SVN版本庫(kù)分支與合并策略2.4.1. 版本庫(kù)管理說(shuō)明源代碼版本管理采用主干和分支的開發(fā)模式，建立分支必然會(huì)涉及到合并，如果要使用主干分支方案就必須接受合并可能帶來(lái)的操作繁復(fù)。源代碼的變動(dòng)主要有幾種：1、建立新項(xiàng)目2、修改bug3、根據(jù)新需求增加新功能4、項(xiàng)目技術(shù)方案重大變革、升級(jí)下面分別對(duì)以上幾種變動(dòng)的操作方案加以說(shuō)明，當(dāng)然實(shí)際操作中并不局限于下面所描述的方案，做為一種建議方案，僅希望提供給大家一種管理思路。2.4.2. 版本庫(kù)操作說(shuō)明分支的合并類型合并的工作是把主干或者分支上合并范圍內(nèi)的

8、所有改動(dòng)列出，并對(duì)比當(dāng)前工作副本的內(nèi)容，由合并者手工修改沖突，然后提交到服務(wù)器的相應(yīng)目錄里。如果當(dāng)前工作副本是主干，則合并的范圍是分支上的改動(dòng)，如果工作副本是分支的，則合并范圍是主干上的改動(dòng)，并且一定要注意，合并的起始位置URL一定要和當(dāng)前的工作副本的URL是相同的。一、合并一個(gè)范圍的版本此類型應(yīng)用最為廣泛，主要是把分支中的修改合并到主干上來(lái)。在主干上點(diǎn)擊右鍵選擇合并，然后選擇合并類型：合并一個(gè)范圍的版本。合并的源URL填寫的是要合并的分支的URL，待合并的版本范圍如果為空，則指的是合并分支上所有的版本，即自從分支創(chuàng)建以來(lái)到分支當(dāng)前最新版本的所有演變。如果只是選擇其中一個(gè)版本，或者幾個(gè)版本，那

9、么就表示只是將制定的n個(gè)版本的變化合并到主干上。如果只是選擇其中一個(gè)版本，那么表示只是選擇那個(gè)版本的修改，之前或之后的修改將不被采納。二、復(fù)興合并復(fù)興合并可以理解為是第一種合并類型的一種特例，在復(fù)興合并中，主干可以理解為是自從開創(chuàng)分支之后沒有任何修改，而分支是經(jīng)過(guò)修改的，而且合并中分支是沒有版本選擇的。經(jīng)過(guò)復(fù)興合并，分支中所有的修改都會(huì)合并到主干中，合并的結(jié)果將使得分支和主干一模一樣，從而可以刪除分支。 三、合并兩個(gè)不同的樹此類型與前兩種類型不同，第一種類型可以選擇分支合并的版本，主干不能選擇版本；第二種類型是主干和分支都不能選擇合并的版本；而這種類型則是無(wú)論是主干還是分支都可以選擇合并的版本

10、，即可以選擇過(guò)去的一個(gè)主干版本與分支的某個(gè)版本進(jìn)行合并。合并的時(shí)候以選擇的分支版本為主，如果選擇的主干版本與分支版本有不同的地方，合并時(shí)主干部分將被放棄。起始URL：選擇主干目錄的URL（應(yīng)當(dāng)和當(dāng)前工作副本的URL一致，這個(gè)是所謂的合并點(diǎn)）結(jié)束URL：選擇要合并的分支的URL。起始和結(jié)束的版本：一般起始版本應(yīng)當(dāng)找到最后一次同步時(shí)的版本，如果從沒有同步過(guò)（第一次合并），則選擇創(chuàng)建分支時(shí)的版本，結(jié)束版本一般是最新版本，如果你不想將某些內(nèi)容合并進(jìn)主干的話，也可以選擇一個(gè)合并點(diǎn)。2.4.3. 各種源碼變動(dòng)時(shí)，版本庫(kù)操作方案2.4.3.1. 建立新項(xiàng)目的操作方案通常建立一個(gè)新項(xiàng)目時(shí)，配置管理人員會(huì)根據(jù)C

11、MMI規(guī)范給我們建立一套完整的項(xiàng)目配置庫(kù)，類似下圖接下來(lái)，我們?cè)谠创a目錄下建立2個(gè)子目錄branchs和trunk，類似下圖Trunk目錄代表源代碼主干，在主干上的代碼通常是經(jīng)過(guò)測(cè)試、功能穩(wěn)定、可以隨時(shí)發(fā)布的項(xiàng)目代碼Branchs目錄代表分支，通常用于功能修改對(duì)于新建立的項(xiàng)目，一般會(huì)由1人或多人搭建項(xiàng)目代碼框架。由多人搭建項(xiàng)目代碼框架時(shí)，每個(gè)人分別在branchs下建立自己的分支，同時(shí)建立1個(gè)集成分支，用于將搭建的代碼框架合并到集成分支下，類似下圖每個(gè)人在自己的工作副本中工作、提交。當(dāng)在規(guī)定時(shí)期做完自己的框架搭建后，按照2.4.2描述的分支合并類型的第一種方法全部合并到集成分支上，類似下圖合

12、并前的圖合并后的圖在集成分支上形成一個(gè)穩(wěn)定的代碼框架版本后，完全可以對(duì)該框架版本進(jìn)行測(cè)試。如果認(rèn)為此代碼框架可以合并到主干上的話，同時(shí)也可以合并到主干上，如果認(rèn)為有必要的話，同時(shí)也可以對(duì)此版本打tag。例如：新建一個(gè)WEB工程項(xiàng)目框架，一般web項(xiàng)目工程都需要用戶和權(quán)限管理模塊，如果該框架集成了公司統(tǒng)一的用戶和權(quán)限管理模塊，完全可以做為全公司web項(xiàng)目工程的基線代碼（當(dāng)然需要統(tǒng)一技術(shù)框架，如：用java開始的項(xiàng)目統(tǒng)一使用開源的ssh技術(shù)框架，以php開始的項(xiàng)目應(yīng)該是不能用）。項(xiàng)目進(jìn)行到這一步后，大家都在集成分支下進(jìn)行共同開發(fā)。全部功能開發(fā)完成后進(jìn)行測(cè)試、修改bug。穩(wěn)定版本后合并到主干上并打t

13、ag。后面操作不再細(xì)述。2.4.3.2. 根據(jù)新需求增加新功能對(duì)于主干上已有穩(wěn)定版本，需要在此版本上增加新的開發(fā)功能的操作方案，細(xì)分的話也有不少，往往會(huì)遇到各種各樣的情況，是在穩(wěn)定的主干版本上新增功能開發(fā)，還是建立分支開發(fā)需要根據(jù)開發(fā)周期來(lái)衡量，最主要的還是技術(shù)主管要根據(jù)需求規(guī)劃好分支，即能方便開發(fā)、方便發(fā)布，又能權(quán)衡好合并帶來(lái)的工作量。舉例說(shuō)明：已有穩(wěn)定的主干項(xiàng)目A，需要在此基礎(chǔ)上增加功能B和功能C1、如果功能B和功能C之間無(wú)依賴、時(shí)間上功能B要先完成，則可以建立2個(gè)分支由2人及以上分別負(fù)責(zé)，分別完成后測(cè)試并分別合并到主干上，并根據(jù)需要打tag。完成功能B后即可以合并到主干上發(fā)布版本，也可以

14、在B分支上發(fā)布版本。2、如果功能C依賴于功能B，時(shí)間上功能B要先完成，則可以建立1個(gè)分支由1人及以上負(fù)責(zé)，完成功能B后測(cè)試并將功能B合并到主干上，發(fā)布版本。完成功能C后再測(cè)試合并到主干上，發(fā)布版本3、做完功能B并合并到主干上了，突然說(shuō)不需要功能B了，只需要功能C。此時(shí)可以在C分支上做測(cè)試、發(fā)布版本。也可以在主干上還原到合并功能B之前的版本，并將功能C合并到主干上做測(cè)試、發(fā)布版本以上只舉例說(shuō)明了3項(xiàng)，實(shí)際過(guò)程中肯定有很多情況。無(wú)論如果變化，堅(jiān)持主干-分支的開發(fā)模式的同時(shí)，也要記住，分支不能過(guò)多，分支一旦超多起來(lái)帶來(lái)的可能是災(zāi)難而不是靈活開發(fā)和發(fā)布。建立分支不要超過(guò)3層。2.4.3.3. 修改bu

15、g的操作方案修改bug的方案，還是離不開分支操作。如果是新建立的項(xiàng)目，通常在分支上開發(fā)完成功能后，可以直接在此分支上修改bug，測(cè)試并合并到主干上打tag對(duì)于已有穩(wěn)定版本的項(xiàng)目，如果修改bug的時(shí)間不長(zhǎng)也可以直接在主干上修改bug，也可以新建分支修改bug，最后測(cè)試合并。2.4.3.4. 項(xiàng)目技術(shù)方案重大變革、升級(jí)的操作方案對(duì)于項(xiàng)目技術(shù)方案重大變革、升級(jí)的操作，一方面可以重新單獨(dú)建立配置庫(kù)，以之前穩(wěn)定的版本做為基線代碼。一方面也可以在主干上建立分支，并以此分支做為變革后的主干2.4.4. 版本庫(kù)發(fā)布模式2.4.4.1. 開發(fā)在主干上進(jìn)行開發(fā)在主干上進(jìn)行，臨近發(fā)布階段，從主干分支出來(lái)，在分支上修

16、訂集成測(cè)試，系統(tǒng)測(cè)試所發(fā)現(xiàn)的bug。在分支上發(fā)布產(chǎn)品升級(jí)包。發(fā)布完成，分支合并到主干。此模式需要對(duì)主干上的開發(fā)周期做一定限制，在主干上開發(fā)的各功能模塊需明確開始時(shí)間與大概結(jié)束的時(shí)間，開發(fā)周期需符合主干上的發(fā)布周期。2.4.4.2. 開發(fā)在分支上進(jìn)行開發(fā)在分支上進(jìn)行，分支上的開發(fā)臨近結(jié)束階段，合并到主干修訂集成測(cè)試、系統(tǒng)測(cè)試所發(fā)現(xiàn)的bug。在主干上發(fā)布產(chǎn)品升級(jí)包。此模式下的開發(fā)周期較靈活，各功能模塊自主定義開發(fā)周期，分支上的開發(fā)臨近末期則合并分支上的開發(fā)至主干。如多個(gè)功能模塊發(fā)布時(shí)間臨近則采取先合并先收益的方式，先合并的分支，在合并過(guò)程中解決的沖突越小。2.4.4.3. 分支的類型2.4.4.3.1.1. 現(xiàn)場(chǎng)版本維護(hù)的分支現(xiàn)場(chǎng)版本的維護(hù)有如下兩種情況：現(xiàn)場(chǎng)版本即為主干上最新版本如現(xiàn)場(chǎng)版本既是主干上最新的版本，從主干上最新版本分支，分支上修改完畢，合并至主干后，在主干上做集成測(cè)試，系統(tǒng)測(cè)試?，F(xiàn)場(chǎng)版本不是主干上最新的版本現(xiàn)場(chǎng)版本不是主干上最新的，即現(xiàn)場(chǎng)的版本屬于之前的某個(gè)時(shí)期的版本，尚未更新至目前最新的。首先確定現(xiàn)場(chǎng)版本，從現(xiàn)場(chǎng)版本的基線分支，在分支上修改完畢，通過(guò)集成測(cè)試，系統(tǒng)測(cè)試，發(fā)布，再合并至主干。2.4.4.3.1.2. 項(xiàng)目技術(shù)方案重大變革、升級(jí)適用于對(duì)主干的重構(gòu)或開發(fā)周期較長(zhǎng)的功能開發(fā)2.4.4.3.2. 根據(jù)新需求增加新功能客戶化分支是永遠(yuǎn)不會(huì)關(guān)閉的分支，它隨著主