管理制度軟件版本管理制度

1、七ij（管理制度）軟件版本管理制度20XX年XX月軟件版本管理規(guī)范系統(tǒng)軟件開發(fā)部2011-9-20目錄1 引言 3目的 31.2范圍 31.3術(shù)語定義 41.4版序控制記錄1.5版本更新記錄2 版本管理 52.1 流程圖 52.2 版本命名 92.3 版本升級 102.3.1 版本升級原則102.3.2 新版本的發(fā)布112.4 目錄結(jié)構(gòu) 122.5 文檔的存放 132.5.1 文本文件的存放 132.5.2 源代碼的存放 132.5.3 發(fā)行文檔的存放 142.6 權(quán)限控制管理 14備份管理 153.1 源文件備份 153.2 庫文件備份 15用戶版本管理 15版本工具的使用 175.1 配置

2、管理工具 175.2CVS的使用 175.2.1常用命令 175.2.2簡單操作 185.2.3版本分支管理 191 引言1.1 目的本文檔是為規(guī)范 XXXXXXXX 公司軟件版本管理而制定的。1.2 范圍本文檔為系統(tǒng)軟件開發(fā)部版本管理員提供有關(guān)版本管理規(guī)范的關(guān)聯(lián)內(nèi)容，包括：版本標(biāo)識方法 軟件系統(tǒng)數(shù)據(jù)的存放 文檔的修改控制 文檔的備份制度1.3 術(shù)語定義CVSCVS是壹個開源的版本控制系統(tǒng)ConcurrentVersionsSystem的簡稱文檔壹種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù)。配置管理標(biāo)識和確定系統(tǒng)中配置項的過程，于系統(tǒng)整個生存周期內(nèi)控制這些項的投放和更動，記錄且方案配置的狀態(tài)和更動要求，驗證

3、配置項的完整性和正確性。軟件配置軟件的具體形態(tài)于某時刻的瞬時影像。配置項軟件配置管理的對象稱為配置項，如：系統(tǒng)規(guī)格說明書，項目開發(fā)計劃，用戶手冊，源碼。基線軟件生存周期中各開發(fā)階段末尾的標(biāo)記，它的作用是把各階段工作的劃分更加明確化，使本來連續(xù)的工作于這些點上斷開，使之便于檢驗和肯定階段成果。1.4版序控制記錄版序狀態(tài)擬稿審核批準(zhǔn)發(fā)布日期1.0系統(tǒng)軟件開發(fā)部1.5版本更新記錄*A-增加M-修改D-刪除版本/修訂版修改頁碼修改記錄修改人日期1.0初始版本2版本管理2.1流程圖2.1.1文檔歸檔流程2.1.2文檔變更流程2.1.3代碼歸檔流程開發(fā)人員測試人員從CVS庫提取源代碼更新版本從CVS庫提取

4、源代碼進(jìn)行編譯打測試版本入庫： 安裝程序 源代碼 測試報告 評審報告2.1.4代碼變更流程2.1.5配置管理流程開發(fā)人員項目管理人員提交測試任務(wù)提交發(fā)布請求測試人員測試計劃、用例回歸測試配置管理員確定版本信息 制做安裝程序新版本發(fā)布入庫 輸出給市場部 發(fā)布文檔更新流程說明:1、開發(fā)人員完成所負(fù)責(zé)模塊的代碼編寫任務(wù)后，提交到項目經(jīng)理處 2、項目經(jīng)理向測試部門提交測試任務(wù) 3、配置管理員準(zhǔn)備測試所需的環(huán)境4、測試人員開展測試且實時提交BUG5、開發(fā)人員處理測試過程中所出現(xiàn)的BUG，且提交給測試人員進(jìn)行回歸測試，直至BUG被關(guān)閉6、測試基本完成后，測試人員提交測試方案 7、項目情況根據(jù)實際情況決定是

5、否發(fā)布新的版本8 、配置管理員和各關(guān)聯(lián)人員經(jīng)討論后確定好新版本各項信息9 、配置管理員發(fā)布新版本2.2 軟件版本命名軟件版本號由四部分組成，第壹個 1 為主版本號，第二個 1 為子版本號，第 三個 1 為階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本 號共有 5 種，分別為：Alpha、Beta、RC、Release。例如：1.1.1.051021_Beta 。對于小項目或子系統(tǒng)而言，可簡化為 主版本號.次版本號.修訂版本號 如 1.0.0。* 主版本號： 當(dāng)功能模塊有較大的變動，比如增加多個模塊或者整體架構(gòu)發(fā)生 變化。此版本號由項目決定是否修改。* 子版本號：當(dāng)功能有壹定的增

6、加或變化，比如增加了對權(quán)限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。*階段版本號：壹般是 Bug 修復(fù)或是壹些小的變動，要經(jīng)常發(fā)布修訂版，時 間間隔不限， 修復(fù)壹個嚴(yán)重的 Bug 即可發(fā)布壹個修訂版。 此版本號由項目經(jīng)理決 定是否修改。* 日期版本號用于記錄修改項目的當(dāng)前日期， 每天對項目的修改均需要更改日 期版本號。此版本號由開發(fā)人員決定是否修改。*Alpha 版:此版本表示該軟件于此階段主要是以實現(xiàn)軟件功能為主，通常只于 軟件開發(fā)者內(nèi)部交流，壹般而言，該版本軟件的 Bug 較多，需要繼續(xù)修改。*Beta版:該版本相對于a版已有了很大的改進(jìn)，消除了嚴(yán)重的錯誤，但仍是 存于著壹些

7、缺陷，需要經(jīng)過多次測試來進(jìn)壹步消除，此版本主要的修改對像是軟件的 UI 。*RC 版:該版本已經(jīng)相當(dāng)成熟了， 基本上不存于導(dǎo)致錯誤的 BUG ，和即將發(fā)行 的正式版相差無幾。*Release 版:該版本意味“最終版本”， 于前面版本的壹系列測試版之后， 終 歸會有壹個正式版本，是最終交付用戶使用的壹個版本。該版本有時也稱為標(biāo)準(zhǔn) 版。壹般情況下， Release 不會以單詞形式出當(dāng)下軟件封面上，取而代之的是符 號(R)。2.3 版本升級2.3.1 版本升級原則版本升級應(yīng)嚴(yán)格納入版本管理的控制之下。應(yīng)當(dāng)謹(jǐn)慎地控制版本的升級，保 障高版本的向下兼容性，或提供嚴(yán)格定義的升級方法。于下面幾種情況下，進(jìn)行

8、版本演化和升級：1、當(dāng)產(chǎn)品發(fā)生重大修改和改進(jìn)時，主版本號加1。重大修改和改進(jìn)包括：1)平臺遷移；2)開發(fā)工具的遷移；3)體系結(jié)構(gòu)的變遷。1。2 、當(dāng)產(chǎn)品發(fā)生較小的改進(jìn)或修改時，次版本號能夠加3、對于改動量比較少的，如修改產(chǎn)品的錯誤，可升級修訂版本號。4 、記錄版本升級過程。每次版本升級，均要填寫版本升級記錄表，記錄表樣例如下:版本升級記錄表主版本子系統(tǒng)名稱子系統(tǒng)版本發(fā)布日期功能變更描述發(fā)布責(zé)任人批準(zhǔn)人備注說明:版本號：記錄當(dāng)前發(fā)布的版本。發(fā)布日期：該版本批準(zhǔn)發(fā)布的日期。修改文件：版本修改記錄文件，壹般為版本修改日志。232新版本的發(fā)布新版本的發(fā)布包括主版本號和次版本號的升級，壹般不包括內(nèi)部版本

9、號的升 級。流程如下:根據(jù)項目進(jìn)展情況，或者根據(jù)用戶需要進(jìn)行發(fā)布準(zhǔn)備。將發(fā)布所需文件進(jìn)行打包，放于指定目錄中，給目錄加上標(biāo)簽Tag，標(biāo)簽中包含將要發(fā)布的版本信息。同樣對源碼文件也要加上和版本信息關(guān)聯(lián)的標(biāo)簽Tag。標(biāo)簽Tag命名規(guī)則如下:組成：模塊首字母+下劃線+文件類型+下劃線+主版本號+次版本號+內(nèi)部版本號+時間（+下劃線+合且標(biāo)記）樣例：qzcj_src_1_0_0_110923 ，qzcj表示采集模塊的首字母，src表示源碼，1_0_0表示將要發(fā)布的版本號，合且標(biāo)記可省略，只于有合且操作時注明，其中合且前的標(biāo)記為 mbe，合且后的標(biāo)記為maf。2.4目錄結(jié)構(gòu)但為了能更好地管理各項目組的文

10、檔， 建議可將被管理的配置項分為三大類: 文檔類、源碼類及安裝盤類，這樣存放比較清晰，有利于版本管理，現(xiàn)將目錄結(jié) 構(gòu)整理如下:根目錄壹級目錄二級目錄對應(yīng)配置項備注resp前置采集源碼源碼后臺計算源碼code業(yè)務(wù)應(yīng)用源碼數(shù)據(jù)庫SQL文件業(yè)務(wù)支撐公用開發(fā)包需求文檔立項方案、需求分析、需求文檔記錄doc設(shè)計文檔軟件架構(gòu)、總體設(shè)計、概要設(shè)計、詳細(xì)設(shè)計、界面設(shè)計發(fā)布文件數(shù)據(jù)庫文檔數(shù)據(jù)字典、數(shù)據(jù)庫搭建、備份仍原方案、PDM設(shè)計測試文檔測試計劃、測試用例、測試方案用戶文檔用戶手冊、產(chǎn)品說明計劃文檔項目計劃、年度月度計劃外部接口文檔標(biāo)準(zhǔn)規(guī)范SET UPreleaserar文件發(fā)布文檔二級目錄中的版本指壹些特殊

11、的版本，不影響基線版本。2.5文檔的存放2.5.1文本文件的存放根據(jù)各項目部自己的情況，將系統(tǒng)用戶需求記錄、總體設(shè)計文檔、詳細(xì)設(shè)計及數(shù)據(jù)結(jié)構(gòu)文件、測試記錄、用戶手冊等放入CVS倉庫doc目錄相應(yīng)的子目錄下。2.5.2源代碼的存放源代碼包括如：java，jsp ， BMP , ICO等關(guān)聯(lián)文件，是未經(jīng)編譯處理的、不能直接交付使用的產(chǎn)品文件以及編譯產(chǎn)品所需的文件； 聯(lián)機(jī)幫助文件 HLP 于未生 成 HLP 文件之前的 DOC ， RTF 等格式的文檔也視為源代碼。各子系統(tǒng)當(dāng)前的程序源文件放入 CVS 倉庫 code 目錄相應(yīng)的 bb 目錄下，對 于壹個子系統(tǒng)又分多個分子系統(tǒng)的情況，應(yīng)于該目錄下分別

12、建立幾個相應(yīng)的子目 錄。2.5.3 發(fā)行文檔的存放發(fā)行文檔是指產(chǎn)品交付用戶使用所必須的文件。包括：產(chǎn)品可執(zhí)行文件，用 戶使用說明書，聯(lián)機(jī)幫助（HLP）;資源文件（BMP , ICO等），環(huán)境配置文件等。之上文檔作為制作發(fā)行盤的素材， 放于 CVS 倉庫發(fā)布文件目錄的 Release 目 錄之下，制作好的發(fā)行盤放于發(fā)布文件的 Setup 目錄。2.6 權(quán)限控制管理為保障文檔的安全性，壹致性，以及防止意外修改，必須對不同的文檔設(shè)置 不同的訪問權(quán)限。文檔權(quán)限類別：無任何權(quán)限，只讀權(quán)限，所有權(quán)限。文檔類別：設(shè)計文檔，源碼，發(fā)行文檔。用戶類別：開發(fā)人員、測試人員、項目經(jīng)理、配置管理員等。為了控制不同的使

13、用權(quán)限，根據(jù)要求于服務(wù)器上分別建立不同的用戶，針對 不同的配置項所于目錄分配不同的權(quán)限。為了便于管理，應(yīng)以表格的形式列出人員和管理對象的訪問關(guān)系（用戶權(quán)限清單），詳見系統(tǒng)部 CVS 權(quán)限配置。3 備份管理為了保證文檔的最大可恢復(fù)性，要隨時及定期地進(jìn)行備份工作。3.1 源文件備份開發(fā)人員每天均要將自已當(dāng)日修改的源文件提交（ commit ）至 CVS 倉庫。3.2 庫文件備份為防止服務(wù)器出現(xiàn)異常，需對服務(wù)器上的 CVS 倉庫文件進(jìn)行備份，目前采用 的方案如下：工作日備份：每個工作日將原本位于 D 盤的倉庫文件于 H 盤上備份壹份， 當(dāng)D 盤倉庫出現(xiàn)異常時，用戶可把 ROOT 目錄修改至 H 盤備

14、份的目錄，再進(jìn)行更 新操作。每周備份：每周五下班時將 H盤備份文件異地備份至其它IP （目前備份于192.168.53.68上）。每月備份：每個月底將最新版本備份至光盤。4 用戶版本管理為了更好地管理源程序，應(yīng)為每壹用戶建立壹個用戶版本文件，該文件應(yīng)包 含以下內(nèi)容：用戶編號: 用戶名稱: 軟件版本號: 開始使用時間: 聯(lián)系人: 聯(lián)系電話: 用戶程序更改日志樣例如下:更改時間版本號修改模塊名稱變更原因變更概述軟件位置變更人員備注說明:用戶購買軟件時要為該用戶建立壹個包含上述內(nèi)容的壹個用戶版本文件，且填寫有關(guān)數(shù)據(jù)。用戶進(jìn)行版本更新時要求填寫該文件的版本變更記錄，用以反映用戶版本的變更情況。5版本工

15、具的使用5.1配置管理工具開發(fā)部采用CVS進(jìn)行配置管理，CVS是壹個C/S系統(tǒng)，多個開發(fā)人員通過 壹個中心版本控制系統(tǒng)來記錄文件版本，從而達(dá)到保證文件同步的目的?？蛻舳藶槟壳?采用的 CVS 服 務(wù)端為 CVSnt-2.5.03.2260TortoiseCVS-1.8.295.2 CVS的使用5.2.1常用命令英文命令中文命令操作、說明備注Checkout提取/取出將文件下載到本地目錄第壹次下載目錄用Commit提交將改動過的文件提交到版本庫每次對文件更新后使用Up date更新將文件同步到最新版本獲取最新版本Tag標(biāo)簽給某個版本添加壹個標(biāo)記符號便于合且分支和主線Branch分支創(chuàng)建某個文件的

16、分支建立特殊版本時用到Merge合且將分支文件（或主文件）的更改合且到主文件（或分支文件）diff比較不同比較任意倆個版本間的不同Revers ion版本分支圖查見文件各版本（包括分支文件）的走向查詢各個版本及 TagGraph圖History歷史查見文件各個版本更新歷史查詢版本詳細(xì)信息522簡單操作文件提取:初次使用需將源文件從倉庫提取出來，執(zhí)行checkout命令將庫文件提取至本地相應(yīng)位置。定時更新:開發(fā)人員每天早上對源代碼或文件進(jìn)行更新操作（右鍵執(zhí)行up date 操作）。實時更新:實時提交:某壹開發(fā)人員提交更改后，可通知其它人員進(jìn)行更新操作。對某壹文件進(jìn)行更改完成后，執(zhí)行commit命

17、令將更改提交至倉庫，更改前先進(jìn)行更新操作，如多個人員對同壹文件同時進(jìn)行操作，會產(chǎn)生沖突，這時需要對沖突進(jìn)行 處理。沖突處理：提交產(chǎn)生沖突時，先對文件進(jìn)行同步（即更新）操作，之后會產(chǎn)生壹個合且文件，< '號前為倆個版本相同部分，='號前為本地版本修改的內(nèi)容，> '前為當(dāng)前服 務(wù)器最新版本修改的內(nèi)容，找到最近提交該文件的同事，進(jìn)行協(xié)商后對源文件進(jìn)行修改且提 交。創(chuàng)建分支/標(biāo)簽：右鍵菜單中選擇Bran ch '或 Tag '找開創(chuàng)建對話框，輸入Branch名或 Tag 名，選中Createnewbranch ' / Createnewtag

18、 '，點擊 OK 即可。查見版本/歷史：文件（非文件夾）右健菜單中選擇 RevisionGraph.'或 History.'可查見該文件的版本更新記錄或歷史信息。5.2.3 版本分支管理我們把壹個項目的主要開發(fā)過程稱作開發(fā)基線。當(dāng)某壹個特殊事件發(fā)生的時 候，例如，有壹個用戶有特殊的需求， 于是就從這個開發(fā)基線里分離出來壹個叉， 以滿足用戶特殊的需求，這個叉有它自己的發(fā)展方向，這就是分支。分支開發(fā)基線上面這個點，代表開發(fā)基線的最新版本，如果從開發(fā)基線建立分支來進(jìn)行定 制開發(fā)，開發(fā)基線和分支就能夠有各自的發(fā)展方向。如果有需要，分支的代碼能 夠重新合且到開發(fā)基線中，開發(fā)基線的代碼也能夠合且到分支代碼中。假設(shè)于我們的 home 目