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

1、軟件源代碼版本管理與發(fā)布版本號:1.1文件編號: 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ù)語41.3.參考資料52.軟件版本管理52.1.版本階段說明52.2.版本命名規(guī)范52.3.版本號修改規(guī)則52.4.SVN版本庫分支與合并策略62.4.1.版本庫管理說明62.4.2.版本庫操作說明62.4.3.各種源碼變動時，版本庫操作方案72.4.4.版本庫發(fā)布模式92.5.版本號發(fā)布132.5.1.版本發(fā)布追

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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