軟件版本管理制度

1、軟件版本管理規(guī)范系統(tǒng)軟件開發(fā)部20119-20目錄 TOC o 1-5 h z 弓1言2 HYPERLINK l bookmark24 o Current Document 1。1目的21。2 范圍2 HYPERLINK l bookmark30 o Current Document 術語定義2 HYPERLINK l bookmark33 o Current Document 版序控制記錄2 HYPERLINK l bookmark36 o Current Document 版本更新記錄3 HYPERLINK l bookmark39 o Current Document 版本管理32。1流

2、程圖32。2版本命名5 HYPERLINK l bookmark60 o Current Document 2。3版本升級6 HYPERLINK l bookmark63 o Current Document 版本升級原則6 HYPERLINK l bookmark73 o Current Document 新版本的發(fā)布6 HYPERLINK l bookmark79 o Current Document 目錄結構7 HYPERLINK l bookmark89 o Current Document 文檔的存放82.5。1文本文件的存放8 HYPERLINK l bookmark86 o Cu

3、rrent Document 2。5。2源代碼的存放82o 5.3 發(fā)行文檔的存放8 HYPERLINK l bookmark92 o Current Document 2。6權限控制管理8 HYPERLINK l bookmark95 o Current Document 備份管理9 HYPERLINK l bookmark98 o Current Document 3o 1源文件備份9 HYPERLINK l bookmark101 o Current Document 3.2 庫文件備份9 HYPERLINK l bookmark104 o Current Document 用戶版本管理

4、9 HYPERLINK l bookmark109 o Current Document 版本工具的使用10 HYPERLINK l bookmark112 o Current Document 配置管理工具10 HYPERLINK l bookmark115 o Current Document CVS的使用10 HYPERLINK l bookmark118 o Current Document 5o 2.1 常用命令10 HYPERLINK l bookmark121 o Current Document 簡單操作10 HYPERLINK l bookmark124 o Current

5、Document 5o 2.3版本分支管理111引言1.1目的本文檔是為規(guī)范XXXXXX有限公司軟件版本管理而制定的。1.2范本文檔為系統(tǒng)軟件開發(fā)部版本管理員提供有關版本管理規(guī)范的相關內(nèi)容，包括:版本標識方法軟件系統(tǒng)數(shù)據(jù)的存放文檔的修改控制文檔的備份制度1.3術語定義CVSCVS是一個開源的版本控制系統(tǒng)Concurrent Versions System的簡稱文檔一種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù).配置管理標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存周期內(nèi)控制這些項的投放和更動， 記錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確性。軟件配置軟件的具體形態(tài)在某時刻的瞬時影像.配置項軟件配置管

6、理的對象稱為配置項，如：系統(tǒng)規(guī)格說明書，項目開發(fā)計劃，用戶手冊， 源碼。基線軟件生存周期中各開發(fā)階段末尾的標記，它的作用是把各階段工作的劃分更加明確 化，使本來連續(xù)的工作在這些點上斷開，使之便于檢驗和肯定階段成果。1.4版序控制記錄版序狀態(tài)擬稿審核批準發(fā)布日期1.0系統(tǒng)軟件開發(fā)部1.5版本更新記錄大A-增加M-修改D -刪除版本/修訂版修改貞碼修改記錄修改人日期1.0初始版本2版本管理2.1流程圖2.1.1文檔歸檔流程2.1.3代碼歸檔流程2.1.42.1.4代碼變更流程2.1.5配置管理流開發(fā)人員測試報告E評，項目管理人員通過2.1.5配置管理流開發(fā)人員測試報告E評，項目管理人員通過測試人員

7、更新版本 （歸檔入庫）流程說明：1、開發(fā)人員完成所負責模塊的代碼編寫任務后，提交到項目經(jīng)理處2、項目經(jīng)理向測試部門提交測試任務3、配置管理員準備測試所需的環(huán)境4、測試人員開展測試并實時提交BUG5、開發(fā)人員處理測試過程中所出現(xiàn)的BUG，并提交給測試人員進行回歸測試，直至BUG被關閉6、測試基本完成后，測試人員提交測試報告7、項目情況根據(jù)實際情況決定是否發(fā)布新的版本8、配置管理員與各相關人員經(jīng)討論后確定好新版本各項信息9、配置管理員發(fā)布新版本2.2軟件版本命名軟件版本號由四部分組成,第一個1為主版本號，第二個1為子版本號，第三個1為 階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本

8、號共有5種，分 別為:Alpha、Beta、RC、Release.例如：1.1。1。051021_Beta。對于小項目或子系統(tǒng)而 言，可簡化為主版本號.次版本號.修訂版本號，如1.0。0.大主版本號：當功能模塊有較大的變動，比如增加多個模塊或者整體架構發(fā)生變化。 此版本號由項目決定是否修改。大子版本號：當功能有一定的增加或變化，比如增加了對權限控制、增加自定義視 圖等功能。此版本號由項目決定是否修改。大階段版本號：一般是Bug修復或是一些小的變動，要經(jīng)常發(fā)布修訂版，時間間 隔不限，修復一個嚴重的Bug即可發(fā)布一個修訂版.此版本號由項目經(jīng)理決定是否修改。*日期版本號用于記錄修改項目的當前日期，每

9、天對項目的修改都需要更改日期版 本號。此版本號由開發(fā)人員決定是否修改。* Alpha版：此版本表示該軟件在此階段主要是以實現(xiàn)軟件功能為主，通常只在軟件 開發(fā)者內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。* Beta版：該版本相對于a版已有了很大的改進，消除了嚴重的錯誤，但還是存在 著一些缺陷，需要經(jīng)過多次測試來進一步消除，此版本主要的修改對像是軟件的UI。大RC版：該版本已經(jīng)相當成熟了，基本上不存在導致錯誤的BUG，與即將發(fā)行的正 式版相差無幾.大Release版：該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有 一個正式版本，是最終交付用戶使用的一個版本。該版本有

10、時也稱為標準版。一般情況 下，Release不會以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號（R）。2.3版本升級2.3.1版本升級原則版本升級應嚴格納入版本管理的控制之下.應當謹慎地控制版本的升級，保障高版本 的向下兼容性，或提供嚴格定義的升級方法。在下面幾種情況下，進行版本演化和升級：1、當產(chǎn)品發(fā)生重大修改和改進時，主版本號加1。重大修改和改進包括：1）平臺遷移；2）開發(fā)工具的遷移；3）體系結構的變遷.2、當產(chǎn)品發(fā)生較小的改進或修改時，次版本號可以加1。3、對于改動量比較少的，如修改產(chǎn)品的錯誤，可升級修訂版本號。4、記錄版本升級過程.每次版本升級，都要填寫版本升級記錄表，記錄表樣例如下:版

11、本升級記錄表主版本子系統(tǒng)名稱子系統(tǒng)版本發(fā)布日期功能變更描述發(fā)布責任人批準人備注說明：版本號：記錄當前發(fā)布的版本。發(fā)布日期：該版本批準發(fā)布的日期。修改文件：版本修改記錄文件，一般為版本修改日志。2.3.2新版本的發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，一般不包括內(nèi)部版本號的升級。流程 如下：1、根據(jù)項目進展情況，或者根據(jù)用戶需要進行發(fā)布準備.2、將發(fā)布所需文件進行打包，放在指定目錄中，給目錄加上標簽Tag,標簽中包 含將要發(fā)布的版本信息.3、同樣對源碼文件也要加上與版本信息相關的標簽Tag.標簽Tag命名規(guī)則如下：組成：模塊首字母+下劃線+文件類型+下劃線+主版本號+次版本號+內(nèi)部版本號+

12、 時間（+下劃線+合并標記）樣例：qzcj_src_1_0_0_110923，qzcj表示采集模塊的首字母,src表示源碼,1_0_0表 示將要發(fā)布的版本號，合并標記可省略，只在有合并操作時注明，其中合并前的標 記為mbe，合并后的標記為maf.2.4目錄結構但為了能更好地管理各項目組的文檔，建議可將被管理的配置項分為三大類：文檔 類、源碼類及安裝盤類，這樣存放比較清晰，有利于版本管理，現(xiàn)將目錄結構整理如下:根目錄一級目錄二級目錄對應配置項備注resp源碼code前置采集源碼后臺計算源碼業(yè)務應用源碼數(shù)據(jù)庫SQL文件業(yè)務支撐公用開發(fā)包文檔doc需求文檔立項報告、需求分析、需求 記錄設計文檔軟件架

13、構、總體設計、概要 設計、詳細設計、界面設計數(shù)據(jù)庫文檔數(shù)據(jù)字典、數(shù)據(jù)庫搭建、備 份還原方案、PDM設計測試文檔測試計劃、測試用例、測試 報告用戶文檔用戶手冊、產(chǎn)品說明計劃文檔項目計劃、年度月度計劃外部接口文檔標準規(guī)范發(fā)布文件SETUPreleaserar文件發(fā)布文檔二級目錄中的版本指一些特殊的版本，不影響基線版本。2.5文檔的存放2.5.1文本文件的存放根據(jù)各項目部自己的情況，將系統(tǒng)用戶需求記錄、總體設計文檔、詳細設計及數(shù)據(jù) 結構文件、測試記錄、用戶手冊等放入CVS倉庫doc目錄相應的子目錄下。2.5.2源代碼的存放源代碼包括如：java,jsp，BMP，ICO等相關文件，是未經(jīng)編譯處理的、不

14、能直接交 付使用的產(chǎn)品文件以及編譯產(chǎn)品所需的文件;聯(lián)機幫助文件HLP在未生成HLP文件之前 的DOC，RTF等格式的文檔也視為源代碼。各子系統(tǒng)當前的程序源文件放入CVS倉庫code目錄相應的bb目錄下，對于一個子 系統(tǒng)又分多個分子系統(tǒng)的情況，應在該目錄下分別建立幾個相應的子目錄。2.5.3發(fā)行文檔的存放發(fā)行文檔是指產(chǎn)品交付用戶使用所必須的文件.包括:產(chǎn)品可執(zhí)行文件，用戶使用說明 書，聯(lián)機幫助（HLP）；資源文件（BMP，ICO等），環(huán)境配置文件等.以上文檔作為制作發(fā)行盤的素材，放在CVS倉庫發(fā)布文件目錄的Release目錄之下， 制作好的發(fā)行盤放在發(fā)布文件的Setup目錄。2.6權限控制管理為

15、保障文檔的安全性，一致性，以及防止意外修改，必須對不同的文檔設置不同的 訪問權限。文檔權限類別：無任何權限，只讀權限，所有權限。文檔類別：設計文檔，源碼，發(fā)行文檔。用戶類別：開發(fā)人員、測試人員、項目經(jīng)理、配置管理員等。為了控制不同的使用權限，根據(jù)要求在服務器上分別建立不同的用戶，針對不同的 配置項所在目錄分配不同的權限。為了便于管理,應以表格的形式列出人員與管理對象的訪問關系（用戶權限清單）， 詳見系統(tǒng)部CVS權限配置。3備份管理為了保證文檔的最大可恢復性，要隨時及定期地進行備份工作。3.1源文件備份開發(fā)人員每天都要將自已當日修改的源文件提交（commit）至CVS倉庫。3.2庫文件備份為防止

16、服務器出現(xiàn)異常，需對服務器上的CVS倉庫文件進行備份，目前采用的方案 如下：工作日備份：每個工作日將原本位于D盤的倉庫文件在H盤上備份一份，當D盤倉 庫出現(xiàn)異常時，用戶可把ROOT目錄修改至H盤備份的目錄，再進行更新操作.每周備份：每周五下班時將H盤備份文件異地備份至其它IP（目前備份在192。168。53。68 上）.每月備份：每個月底將最新版本備份至光盤。4用戶版本管理為了更好地管理源程序，應為每一用戶建立一個用戶版本文件，該文件應包含以下 內(nèi)容：用戶編號：用戶名稱：軟件版本號：開始使用時間：聯(lián)系人：聯(lián)系電話：用戶程序更改日志樣例如下：更改 時間版本號修改模塊名稱變更原因變更概述軟件位置變

17、更 人員備注說明:1）用戶購買軟件時要為該用戶建立一個包含上述內(nèi)容的一個用戶版本文件，并填 寫有關數(shù)據(jù)。2）用戶進行版本更新時要求填寫該文件的版本變更記錄，用以反映用戶版本的變 更情況。5版本工具的使用5.1配置管理工具開發(fā)部采用CVS進行配置管理，CVS是一個C/S系統(tǒng)，多個開發(fā)人員通過一個中心 版本控制系統(tǒng)來記錄文件版本，從而達到保證文件同步的目的。目前采用的 CVS 服務端為 cvsnt2。5.03.2260，客戶端為 TortoiseCVS1.8。29。5.2 CVS的使用5.2.1常用命令央文命令中文命令操作、說明備注Checkout提取/取出將文件下載到本地目錄第一次下載目錄用Co

18、mmit提交將改動過的文件提交到版本庫每次對文件更新后使用Update更新將文件同步到最新版本獲取最新版本Tag標簽給某個版本添加一個標記符號便于合并分支與主線Branch分支創(chuàng)建某個文件的分支建立特殊版本時用到Merge合并將分支文件（或主文件）的更改合并到主文件（或分支文件）diff比較不同比較任意兩個版本間的不同Reversion Graph版本分支圖查看文件各版本（包括分支文件）的走向圖查詢各個版本及TagHistory歷史查看文件各個版本更新歷史查詢版本詳細信息5.2.2簡單操作文件提?。撼醮问褂眯鑼⒃次募膫}庫提取出來，執(zhí)行checkout命令將庫文件提取至本地相應位 置。定時更新

19、:開發(fā)人員每天早上對源代碼或文件進行更新操作（右鍵執(zhí)行update操作）。實時更新：某一開發(fā)人員提交更改后，可通知其它人員進行更新操作.實時提交：對某一文件進行更改完成后，執(zhí)行commit命令將更改提交至倉庫，更改前先進行更 新操作，如多個人員對同一文件同時進行操作,會產(chǎn)生沖突,這時需要對沖突進行處理.沖突處理：提交產(chǎn)生沖突時，先對文件進行同步（即更新）操作，之后會產(chǎn)生一個合并文件，號前為兩個版本相同部分，=號前為本地版本修改的內(nèi)容，前為當前服務器最新版本修改 的內(nèi)容，找到最近提交該文件的同事，進行協(xié)商后對源文件進行修改并提交創(chuàng)建分支/標簽:右鍵菜單中選擇Branch或Tag找開創(chuàng)建對話框，輸入Branch名或Tag名， 選中 Create new branch / Create new tag，點擊 OK 即可。查看版本/歷史：文件（非文件夾）右健菜單中選擇Revision Graph.?；騂istory。.，可查看 該文件的版本更新記錄或歷史信息。5.2.3版本分支管理我們把一個項目的主要開發(fā)過程稱作開發(fā)基線。當某一個特殊事件發(fā)生的時候,例如, 有一個用戶有特殊的需求，于是就從這個開發(fā)基線里分離出來一個叉，以滿足用戶特殊 的需求，這個叉有它自己的發(fā)展方向,這就是分支。分支/開發(fā)基線上面這個點，代